test: add E2E test for power-shaping features #1853
Conversation
WalkthroughThe recent changes aim to bolster blockchain network control by introducing validator caps, allowlists, and denylists for enhanced security and governance in diverse blockchain scenarios, particularly emphasizing partial set security within Opt-In chains. Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
insumity
changed the title
insumity
added
A:backport/v4.2.x
C:x/provider
Co-authored-by: Philip Offtermatt <57488781+p-offtermatt@users.noreply.github.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Review Details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- tests/e2e/steps_partial_set_security.go (1 hunks)
Additional comments not posted (52)
tests/e2e/steps_partial_set_security.go (52)
1004-1005: FunctionstepsValidatorSetCappedChainstarts here.The function name and comment clearly describe its purpose.
1008-1015: Initial chain setup looks good.The validators and their stakes are correctly initialized.
1027-1037: Proposal submission includes theValidatorSetCapfield.The proposal correctly includes the
ValidatorSetCapfield to limit the number of validators.
1057-1071: Opt-in actions for validators are correctly defined.The opt-in actions for
alice,bob, andcarolare correctly defined, ensuring they use the provider's public key.
1106-1114: Assigning the consumer key forcarolis correctly handled.The consumer key assignment for
carolis correctly handled, ensuring proper configuration.
1139-1165: Starting the consumer chain with the validator-set cap is correctly implemented.The consumer chain start action correctly respects the validator-set cap, ensuring only the top validators are included.
1187-1207: Opt-out action forcarolis correctly defined.The opt-out action for
carolis correctly defined, ensuring state changes are accurately captured.
1210-1234: Relay packets action correctly updates the state.The relay packets action correctly updates the state, ensuring the validator set is accurately reflected.
1242-1243: FunctionstepsValidatorsPowerCappedChainstarts here.The function name and comment clearly describe its purpose.
1245-1252: Initial chain setup looks good.The validators and their stakes are correctly initialized.
1264-1273: Proposal submission includes theValidatorsPowerCapfield.The proposal correctly includes the
ValidatorsPowerCapfield to limit the voting power of validators.
1294-1307: Opt-in actions for validators are correctly defined.The opt-in actions for
alice,bob, andcarolare correctly defined, ensuring they use the provider's public key.
1342-1350: Assigning the consumer key forcarolis correctly handled.The consumer key assignment for
carolis correctly handled, ensuring proper configuration.
1375-1401: Starting the consumer chain with the power cap is correctly implemented.The consumer chain start action correctly respects the power cap, ensuring no validator exceeds the specified power limit.
1424-1443: Opt-out action forcarolis correctly defined.The opt-out action for
carolis correctly defined, ensuring state changes are accurately captured.
1446-1470: Relay packets action correctly updates the state.The relay packets action correctly updates the state, ensuring the validator power distribution is accurately reflected.
1478-1479: FunctionstepsValidatorsAllowlistedChainstarts here.The function name and comment clearly describe its purpose.
1481-1488: Initial chain setup looks good.The validators and their stakes are correctly initialized.
1500-1511: Proposal submission includes theAllowlistfield.The proposal correctly includes the
Allowlistfield to specify which validators are allowed.
1531-1544: Opt-in actions for validators are correctly defined.The opt-in actions for
alice,bob, andcarolare correctly defined, ensuring they use the provider's public key.
1579-1587: Assigning the consumer key forcarolis correctly handled.The consumer key assignment for
carolis correctly handled, ensuring proper configuration.
1612-1637: Starting the consumer chain with the allowlist is correctly implemented.The consumer chain start action correctly respects the allowlist, ensuring only the specified validators are included.
1659-1680: Relay packets action correctly updates the state.The relay packets action correctly updates the state, ensuring the validator set is accurately reflected.
1687-1688: FunctionstepsValidatorsDenylistedChainstarts here.The function name and comment clearly describe its purpose.
1691-1698: Initial chain setup looks good.The validators and their stakes are correctly initialized.
1710-1719: Proposal submission includes theDenylistfield.The proposal correctly includes the
Denylistfield to specify which validators are denied.
1740-1753: Opt-in actions for validators are correctly defined.The opt-in actions for
alice,bob, andcarolare correctly defined, ensuring they use the provider's public key.
1788-1796: Assigning the consumer key forcarolis correctly handled.The consumer key assignment for
carolis correctly handled, ensuring proper configuration.
1821-1846: Starting the consumer chain with the denylist is correctly implemented.The consumer chain start action correctly respects the denylist, ensuring the specified validators are excluded.
1868-1889: Relay packets action correctly updates the state.The relay packets action correctly updates the state, ensuring the validator set is accurately reflected.
Line range hint
1-3: FunctionstepsOptInChainstarts here.The function name and comment clearly describe its purpose.
Line range hint
5-15: Initial chain setup looks good.The validators and their stakes are correctly initialized.
Line range hint
17-32: Proposal submission is correctly defined.The proposal submission for adding a consumer chain is correctly defined, including all necessary fields.
Line range hint
34-47: Opt-in actions for validators are correctly defined.The opt-in actions for
aliceandbobare correctly defined, ensuring they use the provider's public key.
Line range hint
49-65: Voting on the proposal is correctly handled.The voting action for the proposal is correctly handled, ensuring the proposal status is updated.
Line range hint
67-84: Starting the consumer chain is correctly implemented.The consumer chain start action is correctly implemented, ensuring the validators are properly initialized.
Line range hint
86-89: Adding IBC connection is correctly defined.The action to add an IBC connection is correctly defined.
Line range hint
91-96: Adding IBC channel is correctly defined.The action to add an IBC channel is correctly defined.
Line range hint
98-107: Opt-in action forcarolis correctly defined.The opt-in action for
carolis correctly defined, ensuring state changes are accurately captured.
Line range hint
109-115: Assigning the consumer key forcarolis correctly handled.The consumer key assignment for
carolis correctly handled, ensuring proper configuration.
Line range hint
117-134: Relay packets action correctly updates the state.The relay packets action correctly updates the state, ensuring the validator set is accurately reflected.
Line range hint
136-143: Opt-out action forbobis correctly defined.The opt-out action for
bobis correctly defined, ensuring state changes are accurately captured.
Line range hint
145-161: Relay packets action correctly updates the state.The relay packets action correctly updates the state, ensuring the validator set is accurately reflected.
Line range hint
163-172: Re-opt-in action forbobis correctly defined.The re-opt-in action for
bobis correctly defined, ensuring state changes are accurately captured.
Line range hint
174-189: Relay packets action correctly updates the state.The relay packets action correctly updates the state, ensuring the validator set is accurately reflected.
Line range hint
191-198: Downtime slash action foraliceis correctly defined.The downtime slash action for
aliceis correctly defined, ensuring state changes are accurately captured.
Line range hint
200-215: Relay packets action correctly updates the state.The relay packets action correctly updates the state, ensuring the validator set is accurately reflected.
Line range hint
217-232: Unjail action foraliceis correctly defined.The unjail action for
aliceis correctly defined, ensuring state changes are accurately captured.
Line range hint
234-249: Relay packets action correctly updates the state.The relay packets action correctly updates the state, ensuring the validator set is accurately reflected.
Line range hint
251-258: Downtime slash action foraliceis correctly defined.The downtime slash action for
aliceis correctly defined, ensuring state changes are accurately captured.
Line range hint
260-275: Relay packets action correctly updates the state.The relay packets action correctly updates the state, ensuring the validator set is accurately reflected.
Line range hint
277-292: Relay packets action correctly updates the state.The relay packets action correctly updates the state, ensuring the validator set is accurately reflected.
There was a problem hiding this comment.
Can you add an entry into the nightly tests? Otherwise it would never run.
https://github.com/cosmos/interchain-security/blob/main/.github/workflows/nightly-e2e.yml#L0-L1
There was a problem hiding this comment.
Actionable comments posted: 1
Out of diff range and nitpick comments (1)
.github/workflows/nightly-e2e.yml (1)
184-199: Ensure consistency in job naming conventions.The job name
partial-set-security-opt-in-testfollows a different naming convention compared to other existing jobs which do not include the word "test" at the end. Consider renaming for consistency.
Review Details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (1)
- .github/workflows/nightly-e2e.yml (2 hunks)
Additional comments not posted (1)
.github/workflows/nightly-e2e.yml (1)
292-297: Good addition of dependency management for the failure notification job.The use of the
needskeyword to ensure that thenightly-test-failjob runs only after all test jobs have completed is a good practice. This helps in managing dependencies between jobs effectively.
| partial-set-security-opt-in-test: | ||
| runs-on: ubuntu-latest | ||
| timeout-minutes: 20 | ||
| steps: | ||
| - uses: actions/setup-go@v5 | ||
| with: | ||
| go-version: "1.21" | ||
| - uses: actions/checkout@v4 | ||
| - name: Checkout LFS objects | ||
| run: git lfs checkout | ||
| - name: Setup Go | ||
| uses: actions/setup-go@v5 | ||
| with: | ||
| go-version: "1.21" # The Go version to download (if necessary) and use. | ||
| - name: E2E partial set security opt-in chain | ||
| run: go run ./tests/e2e/... --tc partial-set-security-opt-in |
There was a problem hiding this comment.
Tip
Codebase Verification
The search results indicate that the test command parameters are defined in the Makefile. However, the specific parameter partial-set-security-opt-in used in the GitHub Actions workflow is not found in the Makefile. This discrepancy suggests that the parameter might be incorrect or missing from the Makefile.
Action Required: Verify Test Command Parameters
The test command parameter partial-set-security-opt-in used in the GitHub Actions workflow does not match any parameters found in the Makefile. Please verify the correctness of this parameter and ensure it is defined appropriately in the Makefile or other relevant files.
- File:
.github/workflows/nightly-e2e.yml - Lines: 184-199
Also applies to:
- Lines 201-215
- Lines 217-231
- Lines 233-247
- Lines 249-263
- Lines 265-279
Analysis chain
Validate the test command parameters.
Ensure that the parameters used in the run commands for each test job match the test cases described in the PR. This is crucial to ensure that the tests are targeting the correct functionalities.
Also applies to: 201-215, 217-231, 233-247, 249-263, 265-279
Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that the test command parameters match the expected test cases as per PR description.
# Test: Search for the test command usage in the e2e test files. Expect: Parameters should match those described in the PR.
rg --type go $'go run ./tests/e2e/... --tc' ./tests/e2e/
Length of output: 57
Script:
#!/bin/bash
# Description: Verify that the test command parameters match the expected test cases as per PR description.
# Test: Search for the test command usage in the e2e test files. Expect: Parameters should match those described in the PR.
# Refine the search pattern to ensure we capture the relevant test command usage.
rg --type go 'go run .*/tests/e2e/.* --tc' ./tests/e2e/
Length of output: 57
Script:
#!/bin/bash
# Description: Verify that the test command parameters match the expected test cases as per PR description.
# Test: Search for the test command usage across the entire repository. Expect: Parameters should match those described in the PR.
rg 'go run .*/tests/e2e/.* --tc'
Length of output: 485
* added E2E tests * Update tests/e2e/steps_partial_set_security.go Co-authored-by: Philip Offtermatt <57488781+p-offtermatt@users.noreply.github.com> * added to nightly tests --------- Co-authored-by: Philip Offtermatt <57488781+p-offtermatt@users.noreply.github.com> (cherry picked from commit a1557bb)
* added E2E tests * Update tests/e2e/steps_partial_set_security.go Co-authored-by: Philip Offtermatt <57488781+p-offtermatt@users.noreply.github.com> * added to nightly tests --------- Co-authored-by: Philip Offtermatt <57488781+p-offtermatt@users.noreply.github.com> (cherry picked from commit a1557bb)
test: add E2E test for power-shaping features (#1853) * added E2E tests * Update tests/e2e/steps_partial_set_security.go Co-authored-by: Philip Offtermatt <57488781+p-offtermatt@users.noreply.github.com> * added to nightly tests --------- Co-authored-by: Philip Offtermatt <57488781+p-offtermatt@users.noreply.github.com> (cherry picked from commit a1557bb) Co-authored-by: insumity <karolos@informal.systems>
test: add E2E test for power-shaping features (#1853) * added E2E tests * Update tests/e2e/steps_partial_set_security.go Co-authored-by: Philip Offtermatt <57488781+p-offtermatt@users.noreply.github.com> * added to nightly tests --------- Co-authored-by: Philip Offtermatt <57488781+p-offtermatt@users.noreply.github.com> (cherry picked from commit a1557bb) Co-authored-by: insumity <karolos@informal.systems>
Description
Added some simple E2E tests to verify that the basic behavior of the power-shaping features works as expected. Specifically, we test that validator-set capping, validators-power capping, allowlisting, and denylisting work.
Verified tests run successfully with:
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
Summary by CodeRabbit
New Features
Tests