-
Notifications
You must be signed in to change notification settings - Fork 8
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
Test governor upgrade for #5 #12
Conversation
Create test harness for testing that the new Governor can execute proposals after the upgrade has completed. Write one test demonstrating the Governor's ability to send GTC already held by the timelock.
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.
still got a few tests left to review
- name: Cache fork requests | ||
uses: actions/cache@v3 | ||
with: | ||
path: ~/.foundry/cache | ||
key: ${{ runner.os }}-foundry-network-fork-${{ github.sha }} | ||
restore-keys: | | ||
${{ runner.os }}-foundry-network-fork- |
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.
This whole step using actions/cache@v3
shouldn't be needed, foundry-rs/foundry-toolchain@v1
now caches automatically
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.
Hm, I removed this in d7b4570 and caching stopped working
For example, you can see that in this build that tests ran to completion, taking 9 minutes. I figured this was expected since we were using a new caching approach -- we'd need to re-cache everything from scratch. So after the build completed I immediately re-ran the workflow to see if things would be faster now. They weren't. I killed the next build after 3 minutes.
For comparison, prior to removing this explicit cache step, fork tests with cached RPC calls were finishing up in ~40s
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.
Hmm yea that's odd. I just ran the same workflow twice:
- https://github.com/gitcoinco/2022-Governor-upgrade/actions/runs/3934573618/jobs/6729444859
- https://github.com/gitcoinco/2022-Governor-upgrade/actions/runs/3934573618/jobs/6729501579
Both took about 4 minutes. I wonder if this line missing logic to create the cache dir if it doesn't exist, so it's never getting saved the first time? Or perhaps we're doing something wrong. Gonna pull in @PaulRBerg to make sure we're not missing anything
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.
Another test:
- Pushed adffed2 which creates the cache directory manually in CI
- CI ran here: https://github.com/gitcoinco/2022-Governor-upgrade/actions/runs/3940835577
- Manually ran another after here: https://github.com/gitcoinco/2022-Governor-upgrade/actions/runs/3940835577
Both took about the same amount of time 🤔
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.
Thanks for the tag, @mds1. Taking a look now.
There might be a bug in the cache implementation - sorry for that. I'm basing this guess on a number of other reports on Twitter.
However, I don't thin't think that this is about the if statement you linked to, i.e. this:
if (fs.existsSync(CACHE_PATHS[0]))
I added that in foundry-rs/foundry-toolchain#21 to prevent another bug that occurred when the user didn't have any fork tests.
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 reverted back to the old approach. I'll leave this thread open for now in case Paul gets back to us, and will plan to merge without resolving.
EDIT: sorry -- didn't see your response above, Paul! I must have not refreshed the page. Appreciate the help!
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.
No worries, David.
After a few hours of debugging (and hundreds of console logs), I have managed to fix this. Waiting for @mds1 or someone else from the team to review my PR and apply the fix:
foundry-rs/foundry-toolchain#24
I am quite confident that the caching should work as expected now!
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.
A couple small comments, but overall really nice job @davidlaprade. Really put the new Governor through its paces. This is looking great!
} | ||
|
||
function delegatesVoteOnBravoGovernor(uint256 _proposalId, uint8 _support) public { | ||
require(_support < 3, "Invalid value for support"); |
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.
Is a require
the right thing to use here? Genuinely asking because I've never thought to use one in a test before, and I've generally opted for asserts instead, but off the top of my head I don't see a reason why require
wouldn't work too.
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.
See #12 (comment) — basically the test assertion helpers don't stop execution of a test when an assertion fails, but in this case (if support >= 3) something went wrong and we don't care about the rest of the test, so it'd just clutter output. In other words, we're using require
because this is input verification, and not a test assertion
test/GitcoinGovernor.t.sol
Outdated
assertEq(_state, IGovernor.ProposalState.Pending); | ||
} | ||
|
||
function _randomERC20Token(uint256 _seed) internal view returns (IERC20 _token) { |
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.
nit: Should we move this helper up above the the first test to keep helpers and tests separate?
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.
Done in b69b4eb
test/GitcoinGovernor.t.sol
Outdated
// else. We also don't want the zero address as a receiver -- if our | ||
// governor is sending tokens to the zero address it could just be due to a | ||
// bug. |
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.
Nit, it is plausible a governor might want to burn tokens for some reason
// else. We also don't want the zero address as a receiver -- if our | |
// governor is sending tokens to the zero address it could just be due to a | |
// bug. | |
// else. We also don't want the zero address as a receiver -- although | |
// this is valid, it's typically not what a governor wants to do |
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.
Updated comment in 4216a16
This PR does a few things: