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
Scripts for verifying bytecodes #5111
Conversation
09aedee
to
a434400
Compare
8ce407b
to
0dbf3bb
Compare
65bcab8
to
a3333ab
Compare
ed84b16
to
8a2df9e
Compare
5c8255f
to
f3c0e87
Compare
8456dcc
to
180d5d8
Compare
#5236) * Simplify contract release process commands and verify release * Revert useful info removals
e2891e8
to
24ea9fb
Compare
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.
Amazing!
# We fetch via HTTPS instead of SSH to avoid the interactive "do you | ||
# trust the RSA key fingerprint" prompt. | ||
git remote add origin-https https://github.com/celo-org/celo-monorepo.git | ||
git fetch origin-https rc1 |
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.
At this point, this is incorrect, as master
needs to compare against release 1.
I believe there are only 3 options:
- Adjust the migrations to proxy linked libraries and then checkout the release-1 branch here
- Create a special case for release 2, where creating the bytecode involves
2.1 Deploying RC1
2.2 Creating the proposal for release 1
2.3 Get through the proposal for release 1
2.4 Continue - Not add this to CI until 1. is done
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.
went with option 3
.circleci/config.yml
Outdated
command: | | ||
./scripts/ci_check_if_test_should_run_v2.sh @celo/protocol | ||
- run: | ||
name: Verify bytecodes between RC1 and current branch |
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.
name: Verify bytecodes between RC1 and current branch | |
name: Verify bytecodes between most recent release and current branch |
# deploy new contracts and generate governance proposal for upgrade | ||
yarn truffle exec --network development ./scripts/truffle/make-release.js --build_directory build/ --report report.json --proposal proposal.json --initialize_data example-initialize-data.json' | ||
NETWORK=${"baklava"|"alfajores"|"mainnet"} | ||
RELEASE="celo-core-contracts-v${N}.${NETWORK}" |
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.
RELEASE="celo-core-contracts-v${N}.${NETWORK}" | |
RELEASE="celo-core-contracts-v${N-1}.${NETWORK}" |
I think?
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 trying to generalize this and add the specific instruction in backward compatibility check but this is probably the primary use case
RELEASE="celo-core-contracts-v${N}.${NETWORK}" | ||
# A -f boolean flag can be provided to use a forno full node to connect to the provided network | ||
# A -r boolean flag should be provided if this is the first release (before linked libraries were proxied) | ||
yarn verify-deployed -n $NETWORK -b $RELEASE -r -f |
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 don't think it's in scope for this PR, but for these critical scripts, I'm not sure I'm a fan of these shortened flags, wdyt?
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.
agreed
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.
will address in followup PR
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.
LGTM
Description
Adds two bash wrappers around
verify-bytecodes
:verify-deployed
checks that the current Celo contracts correspond to Solidity sources on a given branch.verify-release
checks that after executing a given proposal, the onchain contracts will correspond to Solidity sources on a given branch.Other changes
Added a
-f
flag to several of our bash scripts, and modifiedtruffle-config
to take a--forno
parameter that allows Truffle scripts to run with a Forno provider on testnets/the mainnet for which a Forno instance exists.Added comments, cleaned up scripts.
Tested
verify-deployed
verify-release
Related issues
Backwards compatibility
+1