Skip to content
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

Merged
merged 27 commits into from
Jan 17, 2023
Merged

Conversation

davidlaprade
Copy link
Contributor

@davidlaprade davidlaprade commented Jan 12, 2023

This PR does a few things:

  • adds a fuzz seed to the .env template to reduce RPC calls and speed up local test runs
  • it renames some test variables to make it clearer which governor instance we're interacting with
  • it adds some tests:
    • that proposals can be defeated by the new governor
    • that miscellaneous token sends can be executed by the new governor
    • that settings on the new governor can be updated
    • that mixed votes (some for, some against) resolve correctly on the new governor
    • that votes on the abandoned alpha governor don't affect votes on the active bravo governor
  • it adds RPC request caching persistence to CI

@davidlaprade davidlaprade marked this pull request as ready for review January 13, 2023 20:24
@davidlaprade davidlaprade requested review from apbendi and mds1 January 13, 2023 20:24
Copy link
Collaborator

@mds1 mds1 left a 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

.env.template Outdated Show resolved Hide resolved
.github/workflows/ci.yml Outdated Show resolved Hide resolved
Comment on lines +44 to +50
- 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-
Copy link
Collaborator

@mds1 mds1 Jan 16, 2023

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

Copy link
Contributor Author

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

Copy link
Collaborator

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:

  1. https://github.com/gitcoinco/2022-Governor-upgrade/actions/runs/3934573618/jobs/6729444859
  2. 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

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another test:

  1. Pushed adffed2 which creates the cache directory manually in CI
  2. CI ran here: https://github.com/gitcoinco/2022-Governor-upgrade/actions/runs/3940835577
  3. Manually ran another after here: https://github.com/gitcoinco/2022-Governor-upgrade/actions/runs/3940835577

Both took about the same amount of time 🤔

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.

Copy link
Contributor Author

@davidlaprade davidlaprade Jan 17, 2023

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!

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!

test/GitcoinGovernor.t.sol Outdated Show resolved Hide resolved
test/GitcoinGovernor.t.sol Show resolved Hide resolved
test/GitcoinGovernor.t.sol Outdated Show resolved Hide resolved
test/GitcoinGovernor.t.sol Outdated Show resolved Hide resolved
test/GitcoinGovernor.t.sol Outdated Show resolved Hide resolved
test/GitcoinGovernor.t.sol Outdated Show resolved Hide resolved
test/GitcoinGovernor.t.sol Outdated Show resolved Hide resolved
test/GitcoinGovernor.t.sol Outdated Show resolved Hide resolved
test/GitcoinGovernor.t.sol Show resolved Hide resolved
test/GitcoinGovernor.t.sol Outdated Show resolved Hide resolved
test/GitcoinGovernor.t.sol Show resolved Hide resolved
Copy link
Collaborator

@apbendi apbendi left a 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");
Copy link
Collaborator

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.

Copy link
Collaborator

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 Show resolved Hide resolved
assertEq(_state, IGovernor.ProposalState.Pending);
}

function _randomERC20Token(uint256 _seed) internal view returns (IERC20 _token) {
Copy link
Collaborator

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?

Copy link
Contributor Author

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 Show resolved Hide resolved
Comment on lines 448 to 450
// 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.
Copy link
Collaborator

@mds1 mds1 Jan 17, 2023

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

Suggested change
// 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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated comment in 4216a16

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants