Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Refactor workflows to add deployment of contracts migrated on Celo #2492
Refactor workflows to add deployment of contracts migrated on Celo #2492
Changes from 1 commit
3578a8d
76adcf0
2d969b3
c0b590d
f5bb7d0
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
We could handle these two in a one step if we update env variables names expected by the truffle configuration (see the other comment).
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.
My understanding is that if we'd switch to setting
CHAIN_API_URL
andCONTRACT_OWNER_ACCOUNT_PRIVATE_KEY
environment variables, we would still need to populate those variables with different values, depending on the network used. Is there a way to do that in one step?Maybe there is a way to do something like this?:
(I don't know how to do that with operators supported by GitHub)
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'm afraid it's not yet supported by GHA 😞
See: actions/runner#409
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.
Renaming the image will require aligning the kubernetes configs.
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.
Are those configs stored on the repo? Could you guide me where to find them?
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.
Please grep ocurrences under
./infrastructure/kube/keep-dev
and./infrastructure/kube/keep-test
.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've changed the Kubernetes config and also modified the image name in the workflow to use chain name in the suffix instead of the environment/network. In order for this to work, keep-network/ci#6 needs to be merged to master, so please merge that PR before merging the current one.
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.
Maybe we should expect the same-named env variables for all networks.
So instead of having
ETH_HOSTNAME
andCELO_HOSTNAME
we could expectCHAIN_API_URL
,and instead of
CONTRACT_OWNER_ETH_ACCOUNT_PRIVATE_KEY
andCONTRACT_OWNER_CELO_ACCOUNT_PRIVATE_KEY
we could expectCONTRACT_OWNER_ACCOUNT_PRIVATE_KEY
.This will make the migrations more generic, hence from the CI workflows perspective, we could handle both Ethereum and Celo migrations in one step.
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 did unified the variables (see 76adcf0), but I'm not sure if it will allow us to handle both migrations in one step (see my comment below).
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 was also thinking about loading secrets for the environemnt based on the environment property. So we would name the GH environments the same as we expect workflow dispatch
environment
property to be set.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.
The downside of this solution would be the need to repeat the same settings across different repositories. Sticking with current solution seems to be the least complicated.