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

Add compatibility tests for v5.0.x #2 #2396

Merged
merged 28 commits into from
Sep 28, 2022

Conversation

chatton
Copy link
Contributor

@chatton chatton commented Sep 26, 2022

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.

  • Targeted PR against correct branch (see CONTRIBUTING.md)
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Code follows the module structure standards.
  • Wrote unit and integration tests
  • Updated relevant documentation (docs/) or specification (x/<module>/spec/)
  • Added relevant godoc comments.
  • Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
  • Re-reviewed Files changed in the Github PR explorer
  • Review Codecov Report in the comment section below once CI passes

@@ -0,0 +1,50 @@
on:
workflow_call:
Copy link
Contributor Author

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.

@@ -0,0 +1,15 @@
{
Copy link
Contributor Author

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.

@chatton chatton marked this pull request as ready for review September 27, 2022 08:57
@chatton
Copy link
Contributor Author

chatton commented Sep 27, 2022

@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
Copy link
Contributor Author

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"
Copy link
Contributor Author

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!

Copy link
Member

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/...

Copy link
Member

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?

Copy link
Contributor Author

@chatton chatton Sep 27, 2022

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?

Copy link
Member

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

Copy link
Contributor

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!

Copy link
Member

@damiannolan damiannolan left a 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:

❤️

Comment on lines +4 to +10
inputs:
release-branch:
description: 'Release branch to test'
required: true
type: choice
options:
- release/v5.0.x
Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Member

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"
Copy link
Member

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"
Copy link
Member

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) }}
Copy link
Member

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?

Copy link
Contributor Author

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)

Copy link
Contributor

Choose a reason for hiding this comment

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

This is indeed magic 😅

Copy link
Contributor Author

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 😓

@chatton
Copy link
Contributor Author

chatton commented Sep 27, 2022

@damiannolan

Will we also need to add blocks for interchain-accounts here?

Currently all the interchain accounts tests are running using the icad, so the state of the release branch in ibc-go should have no impact here right?

I'm not sure I understand fully here. Could you provide me with the verbose output

Right maybe I can add some clarification, the tests themselves exist under e2e/... but the matrix files for the workflow live separately (the new dir added in this PR) compatibility-test-matrices.

This additional field e.g. test-suite: "transfer" is literally just a convention I'm using to pass arguments to the reusable workflow so that we can run any test suite the same way by adhering to a directory structure.

compatibility-test-matrices/<release-<version>/<test-suite>.json

Copy link
Contributor

@colin-axner colin-axner left a 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) }}
Copy link
Contributor

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"
Copy link
Contributor

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!

Comment on lines +2 to +3
"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"],
Copy link
Contributor

Choose a reason for hiding this comment

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

so clean! ❤️

@colin-axner
Copy link
Contributor

Currently all the interchain accounts tests are running using the icad, so the state of the release branch in ibc-go should have no impact here right?

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?)

@chatton
Copy link
Contributor Author

chatton commented Sep 28, 2022

@colin-axner

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 Manual E2E (Icad) test. But I think long term will be able to use simd and it can be added as a new file here.

@chatton chatton merged commit 0d63964 into main Sep 28, 2022
@chatton chatton deleted the cian/add-additional-tests-for-v5-github-matrix branch September 28, 2022 12:41
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.

3 participants