-
Notifications
You must be signed in to change notification settings - Fork 617
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: e2e setup to be more extensible for state sync #1565
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1565 +/- ##
=======================================
Coverage 19.47% 19.47%
=======================================
Files 242 242
Lines 32258 32258
=======================================
Hits 6282 6282
Misses 24822 24822
Partials 1154 1154 Continue to review full report at Codecov.
|
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.
Great work, and thank you for cleaning up some of my the code mess I made!
// It is used when skipping upgrade by setting OSMOSIS_E2E_SKIP_UPGRADE to true). | ||
// This image should be pre-built with `make docker-build-debug` either in CI or locally. | ||
LocalOsmoRepository = "osmosis" | ||
LocalOsmoTag = "debug" |
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.
Can you explain why this value gets exported but the others dont?
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.
Because we need to reuse it outside of the package for the upgrade:
osmosis/tests/e2e/e2e_setup_test.go
Line 553 in 3ddd10a
Repository: dockerconfig.LocalOsmoRepository, |
// Run a relayer between every possible pair of chains. | ||
for i := 0; i < len(s.chainConfigs); i++ { | ||
for j := i + 1; j < len(s.chainConfigs); j++ { | ||
s.runIBCRelayer(s.chainConfigs[i].chain, s.chainConfigs[j].chain) |
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.
Do you think this abstraction is worth it? There might be some benefit to reducing the scope of end to end tests to a max of two chains. With that being said, totally open to expanding the scope
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 thinking of still having the 2 chains but aiming to design for extensibility. So that if we want to add a third chain for any reason, like testing some ibc functionality in the future, it works out of the box.
The primary reason for this refactor though is to just encapsulate more "chain-specific" data under the same abstraction. That allows me to add more methods on that abstraction related to state-sync. This particular change is secondary and doesn't add more value to the end goal
s.createPool(s.chains[0], "pool1A.json") | ||
s.createPool(s.chains[1], "pool1B.json") | ||
chainA := s.chainConfigs[0].chain | ||
chainB := s.chainConfigs[1].chain |
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.
Love this, makes it way easier to think of instead of using chain[0] as chain A
Thanks for the speedy review @czarcas7ic . Let me know if I can help rebasing your change against this one |
Closes: #XXX This PR refactors e2e test setup to have an abstraction `chainConfig` that has information about which validators should not be run during initialization. This is a first step toward testing state-sync as we want to postpone running some nodes so that we can test nodes "catching up". Additionally, this PR extracts a separate package `docker` for managing and storing all information related to docker images. - create a `chainConfig` struct to encapsulate all configurations related to chains in a single abstraction * remove global variables `propHeightA`, `propHeightB`, `votingPeriodA`, `votingPeriodB`. Instead, these are part of the `chainConfig` struct * `skipRunValidatorIndexes` - this is needed to skip certain validators from being run during setup so that we can test state-sync post-initialization and upgrade - remove code duplication for every chain. Instead, always loop over `chainConfig`s so that if we add more chains later, the setup would work out of the box - tested running both with and without upgrade - Does this pull request introduce a new feature or user-facing behavior changes? no - Is a relevant changelog entry added to the `Unreleased` section in `CHANGELOG.md`? no - How is the feature or change documented? not applicable
* change to osmo no stake * currently working * superfluid vote overwrite test * change docker file * refactor: e2e setup to be more extensible for state sync (#1565) Closes: #XXX This PR refactors e2e test setup to have an abstraction `chainConfig` that has information about which validators should not be run during initialization. This is a first step toward testing state-sync as we want to postpone running some nodes so that we can test nodes "catching up". Additionally, this PR extracts a separate package `docker` for managing and storing all information related to docker images. - create a `chainConfig` struct to encapsulate all configurations related to chains in a single abstraction * remove global variables `propHeightA`, `propHeightB`, `votingPeriodA`, `votingPeriodB`. Instead, these are part of the `chainConfig` struct * `skipRunValidatorIndexes` - this is needed to skip certain validators from being run during setup so that we can test state-sync post-initialization and upgrade - remove code duplication for every chain. Instead, always loop over `chainConfig`s so that if we add more chains later, the setup would work out of the box - tested running both with and without upgrade - Does this pull request introduce a new feature or user-facing behavior changes? no - Is a relevant changelog entry added to the `Unreleased` section in `CHANGELOG.md`? no - How is the feature or change documented? not applicable * add extract oper address * extract val addr * new line * delete no longer needed script * Delete .bash_history * add helper functions to declutter * remove majority boilerplate * move docker file back to distroless * no longer use bash to add account * remove debugging print statements * Delete .bash_history * remove extra line in docker file * Apply suggestions from code review Co-authored-by: Roman <[email protected]> * code review suggestions * further validator abstractions Co-authored-by: Roman <[email protected]>
Closes: #XXX
What is the purpose of the change
This PR refactors e2e test setup to have an abstraction
chainConfig
that has information about which validators should not be run during initialization. This is a first step toward testing state-sync as we want to postpone running some nodes so that we can test nodes "catching up".Additionally, this PR extracts a separate package
docker
for managing and storing all information related to docker images.Brief Changelog
chainConfig
struct to encapsulate all configurations related to chains in a single abstractionpropHeightA
,propHeightB
,votingPeriodA
,votingPeriodB
. Instead, these are part of thechainConfig
structskipRunValidatorIndexes
- this is needed to skip certain validators from being run during setup so that we can test state-sync post-initialization and upgradechainConfig
s so that if we add more chains later, the setup would work out of the boxTesting and Verifying
Documentation and Release Note
Unreleased
section inCHANGELOG.md
? no