-
Notifications
You must be signed in to change notification settings - Fork 134
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: support backward compatiblity checks in e2e testing #1656
Conversation
854f3a4
to
f2ba52b
Compare
f2ba52b
to
d0d88d1
Compare
7f73e92
to
bebe958
Compare
bebe958
to
835c3cd
Compare
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.
Thanks for the work! Mostly looks good, left a couple of comments. I think in particular we need a bit more documentation on this.
I think a lot of this means extra work when we do new releases, and this will for sure be an extra maintenance burden - I'd suggest thinking of ways we can make this e.g. fail visibly when we make a new release and something hasn't been updated properly on the compatibility tests, e.g. somewhere the new release is not set as the latest version
fmt.Println("Using old validator configs: ", providerVersion) | ||
|
||
validatorCfg = map[ValidatorID]ValidatorConfig{ | ||
ValidatorID("alice"): { |
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 wonder if there is some common kernel that we should try to pull out here to reduce duplication, but maybe it's not possible or worth it - just from looking at a diffchecker, a few things seem to be common among versions, but maybe not enough to justify effort to unify it
894e591
to
f15cde8
Compare
c882f59
to
0760c47
Compare
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.
LGTM, thanks for addressing the comments.
I think this would benefit from having someone who is more involved in the release process take a look. I am slightly concerned this introduces a lot of changes when we release a new version, but I don't really have the experience to say.
@MSalopek @mpoke I think one of you should probably have a look
@p-offtermatt This PR doesn't modify any production code, thus it doesn't affect the release process. |
It does not affect releasing. There could be further changes for later versions and we may need to revisit the compatility matrix (some versions will not be complatible because of test initialization, differenc CLI comands used etc.) |
Yeah, the points you made are what I was wondering about, not the release process itself, probably didn't express that clearly. |
* Infra for compatibility tests * Dockerfile fix for hermes * cleanup fix gosec + refactor * adapt actions to target * Cleanup docker files * log cleanup * addressed comments * fix image cleanup * addressed PR comments * some more gosec fixes * ignore errors when trying to remove non-existing containers * updated e2e README * addressed remaining linter warning + caching & worktree improvement * docker image: use cometmock from provider image * fix testscript path * Addressed comments from @sainoe * Added compatibility tests * Added support using images from GH registry. Added version dependent config * Added test report + fixes * nit * addressed gosec issues + nit * try Makefile fix * Fix makefile * Addressed comments * added comment for transform parameter identification
Description
Closes: #1559
Add backward compatibility tests to e2e testing
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...