-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migration to add keys to service accounts for testing #6969
Migration to add keys to service accounts for testing #6969
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #6969 +/- ##
==========================================
- Coverage 43.29% 41.09% -2.20%
==========================================
Files 1558 2130 +572
Lines 139443 186669 +47226
==========================================
+ Hits 60366 76719 +16353
- Misses 74026 103524 +29498
- Partials 5051 6426 +1375
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
@@ -422,6 +422,8 @@ func run(*cobra.Command, []string) { | |||
var migs []migrations.NamedMigration | |||
|
|||
switch flagMigration { | |||
case "add-keys": |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
case "add-keys": | |
case "add-migrationnetwork-keys": |
maybe making the purpose a bit more clear and specific.
} | ||
|
||
// add key to node accounts | ||
for _, nodeAddress := range mainnetNodeAddresses { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As double protection, I would suggest to use a emptyNodeAddresses
here. So in order to use it, both emptyNodeAddresses
and IAmSureIWantToRunThisMigration
have to be updated. Updating only one would only be a no-op.
for _, nodeAddress := range mainnetNodeAddresses { | |
for _, nodeAddress := range emptyNodeAddresses { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think these will change over time? wouldn't it be better to just have them prepared here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean we keep the mainnetNodeAddresses
variable, but we create another emptyNodeAddresses
variable. And by default the emptyNodeAddresses
is used, so that this is a double protection.
Then, in order to use it in migration mainnet, we need to do 2 things:
- set
IAmSureIWantToRunThisMigration
to true - replace
emptyNodeAddresses
withmainnetNodeAddresses
here.
And if we forgot to do step 2, the IHaveReplacedEmptyNodeAddressesToMainnetAddresses
is still false, and the error will remind us.
And if we updated IHaveReplacedEmptyNodeAddressesToMainnetAddresses
to true, but didn't actually do step 2, then it will still be a no-op.
Does it make sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what about requiring a specific chainID instead?
I think it's more likely that we accidentally merge code with the updated config so adding a check that we wouldn't need to change would help avoid accidental merges allowing this migration against a main network.
if !IAmSureIWantToRunThisMigration { | ||
panic("Cannot run AddKeyMigration migration") | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better to add another "checkbox" to remind the required step:
if !IHaveReplacedEmptyNodeAddressesToMainnetAddresses { | |
panic("didn't use the mainnet node addreses") | |
} |
reporter reporters.ReportWriter | ||
} | ||
|
||
var _ AccountBasedMigration = &AddKeyMigration{} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
var _ AccountBasedMigration = &AddKeyMigration{} | |
var _ AccountBasedMigration = (*AddKeyMigration)(nil) |
// This migration is not safe to run on actual networks. | ||
// It is used for getting control over system accounts so that they can be tested | ||
// in a copied environment. When we need to do this it is best to create a branch | ||
// where this variable is set to true, and use that temporary branc to run migrations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// where this variable is set to true, and use that temporary branc to run migrations. | |
// where this variable is set to true, and use that temporary branch to run migrations. |
} | ||
|
||
// add key to node accounts | ||
for _, nodeAddress := range mainnetNodeAddresses { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what about requiring a specific chainID instead?
I think it's more likely that we accidentally merge code with the updated config so adding a check that we wouldn't need to change would help avoid accidental merges allowing this migration against a main network.
…mainnet-add-keys-to-core-contracts-master
I changed the Add key migration (originally added here: #6926) so that the code can be committed to master, but it is not runnable without changing this constant
IAmSureIWantToRunThisMigration
. If you change it the test will start failing which would then prevent you from accidentally merging that branch.see: #6970