-
Notifications
You must be signed in to change notification settings - Fork 627
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
Add compatibility tests for v5.0.x #2 #2396
Add compatibility tests for v5.0.x #2 #2396
Conversation
…nal-tests-for-v5-github-matrix
@@ -0,0 +1,50 @@ | |||
on: | |||
workflow_call: |
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 is a re-usable workflow that we can call for each test suite.
…s://github.com/cosmos/ibc-go into cian/add-additional-tests-for-v5-github-matrix
@@ -0,0 +1,15 @@ | |||
{ |
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.
these values get expanded so the workflow runs with every permutation of these values.
@colin-axner & @charleenfei thank you for reviewing #2370 after some discussion with @crodriguezvega and looking some more into Colin's suggestion, I refactored the workflow to be (much) more maintainable. The workflows are largely the same, it's mostly just the smaller config file we need to manage. |
needs: | ||
- build-release-image | ||
- determine-docker-tag | ||
uses: ./.github/workflows/e2e-compatibility-workflow-call.yaml |
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 is how workflows can be re-used in github actions.
uses: ./.github/workflows/e2e-compatibility-workflow-call.yaml | ||
with: | ||
docker-tag: "${{ needs.determine-docker-tag.outputs.docker-tag }}" | ||
test-suite: "transfer" |
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.
these strings map to sub directories, I'm open to alternatives if there are any suggestions!
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'm not sure I understand fully here. Could you provide me with the verbose output? 😅
I initially thought you meant they correspond to the directory under e2e/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.
Will we also need to add blocks for interchain-accounts
here?
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.
maybe we could rename the value to be something more explicit like matrix-filename
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.
I'm easy. I think its fine to leave as is
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.
Whatever is fine by me!
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.
Just left a few questions, I'm getting a better grasp on the workflows, slowly but surely its becoming easier to parse.
The yaml gods have spoken! ⚒️⚡
L:
G:
T:
M:
❤️
inputs: | ||
release-branch: | ||
description: 'Release branch to test' | ||
required: true | ||
type: choice | ||
options: | ||
- release/v5.0.x |
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.
So do we need to add all release branches we want to test with here?
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.
yes - this is just for a dropdown, if we prefer, we can have a text box and enter anything we like. I just think the dropdown is better UX
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.
Agree!
uses: ./.github/workflows/e2e-compatibility-workflow-call.yaml | ||
with: | ||
docker-tag: "${{ needs.determine-docker-tag.outputs.docker-tag }}" | ||
test-suite: "transfer" |
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'm not sure I understand fully here. Could you provide me with the verbose output? 😅
I initially thought you meant they correspond to the directory under e2e/tests/...
uses: ./.github/workflows/e2e-compatibility-workflow-call.yaml | ||
with: | ||
docker-tag: "${{ needs.determine-docker-tag.outputs.docker-tag }}" | ||
test-suite: "transfer" |
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 we also need to add blocks for interchain-accounts
here?
needs: load-test-matrix | ||
strategy: | ||
fail-fast: false | ||
matrix: ${{ fromJSON(needs.load-test-matrix.outputs.test-matrix) }} |
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.
Aha, so this magic uses load-test-matrix
to parse the JSON files and set the values in matrix
which is used below to run the e2e test and populate the env?
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.
yes the previous job load-test-matrix
stores a json string as its output (the contents of a json file depending on args) and the matrix
field accepts dynamic input (or statically defined in the workflow)
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 is indeed magic 😅
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.
the process of passing variables between steps is quite cumbersome unfortunately 😓
Currently all the interchain accounts tests are running using the icad, so the state of the release branch in
Right maybe I can add some clarification, the tests themselves exist under This additional field e.g.
|
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.
absolutely fabulous! 👑
These e2e test additions are like a dream come true!
needs: load-test-matrix | ||
strategy: | ||
fail-fast: false | ||
matrix: ${{ fromJSON(needs.load-test-matrix.outputs.test-matrix) }} |
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 is indeed magic 😅
uses: ./.github/workflows/e2e-compatibility-workflow-call.yaml | ||
with: | ||
docker-tag: "${{ needs.determine-docker-tag.outputs.docker-tag }}" | ||
test-suite: "transfer" |
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.
Whatever is fine by me!
"chain-a": ["release-v5.0.x", "v4.1.0", "v3.3.0", "v2.4.0"], | ||
"chain-b": ["release-v5.0.x", "v4.1.0", "v3.3.0", "v2.4.0"], |
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.
so clean! ❤️
I guess the question is if we want to be able to trigger icad compatibility tests from ibc-go as well (long term no, but maybe in the short term?) |
Right, we can already do this with the |
Description
This PR replaces #2370
This is a re-work of the referenced PR. Instead of using a large json file per release branch, this method allows us to define smaller, more maintainable files per release branch / test suite pair.
Sample workflow: here
Update: One additional benefit, each job is limited to creating 256 tasks. A github workflow can have multiple jobs, i.e. transfer, client, incentivized etc. While we are not at that level yet (transfer test is creating 80), splitting up like this leaves more room for growth without refactoring how the tests run in the future.
closes #2370
Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.
docs/
) or specification (x/<module>/spec/
)godoc
comments.Unreleased
section inCHANGELOG.md
Files changed
in the Github PR explorerCodecov Report
in the comment section below once CI passes