-
Notifications
You must be signed in to change notification settings - Fork 231
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 integration test pinned to tendermint-go v0.33.5 #324
Add integration test pinned to tendermint-go v0.33.5 #324
Conversation
Codecov Report
@@ Coverage Diff @@
## master #324 +/- ##
======================================
Coverage 30.5% 30.5%
======================================
Files 127 127
Lines 4581 4581
Branches 1416 1416
======================================
Hits 1398 1398
Misses 2216 2216
Partials 967 967 Continue to review full report at Codecov.
|
@@ -35,7 +35,6 @@ mod rpc { | |||
async fn abci_info() { | |||
let abci_info = localhost_rpc_client().abci_info().await.unwrap(); | |||
|
|||
assert_eq!(&abci_info.version, "0.17.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.
See the specific commit message for my reasoning here: b452fcc
An important caveat (tho not well placed in the git logs), is that I don't have a very informed position, given that this is my first tiny foray into helping here, so please forgive if my suggestions are wide of the mark.
Some alternatives that might make sense, in addition to the approach I propose in the commit message:
- Specify the expected version via an environment variable during testing (allowing us to support testing against multiple versions, as desired).
- Change this to a check for a string that matches a semantic version (e.g.,
\d+\.\d+\.\d+
)
b452fcc
to
adc3101
Compare
This change should make it possible to make the |
adc3101
to
e2c444a
Compare
.github/workflows/rust.yml
Outdated
@@ -61,11 +61,34 @@ jobs: | |||
command: test | |||
args: --all-features --no-fail-fast | |||
|
|||
test-integration-ignored: | |||
# TODO(shonfeder): remove duplication once GitHub addresses |
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.
IIUC, we could DRY this out now if we want to define our own action for this, but I'm not sure if we want to complicate the CI config that way. I'm up for it tho, if anyone thinks it's preferable.
runs-on: ubuntu-latest | ||
services: | ||
tendermint: | ||
image: tendermint/tendermint | ||
image: tendermint/tendermint:v0.33.5 |
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.
It would be nice to set this version somewhere more canonical, but from what I've seen of github actions so far, there's no clear way to parameterize the values of an image
field here. I'd be interested in suggestions for a more elegant approach here. Failing that, I could at least document this somewhere (and the question is just where that should go).
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 don't have much experience with gh either. I think even having the version more prominently in an env variable, might be ok: https://help.github.com/en/actions/configuring-and-managing-workflows/using-environment-variables
@marbar3778 as you looked a lot more into GA, do you have a suggestion how to parameterize this?
Closes informalsystems#304 Also renames test-integration-ignored to test-integration-latest. With this change, CI runs two integration tests: 1. A `stable` test to protect against regressions, run against a pinned version of the tendermint/tendermint docker image. 2. A `latest` test to track whether we're maintaining parity with the latest development version of tendermint-go. Signed-off-by: Shon Feder <shon@informal.systems>
Hardcoding a test for the version in this way makes it impossible to run the integration tests against different ABCI versions. This change proposes one solution to address this problem and to the underlying issue behind, e.g., - informalsystems#249 - informalsystems#238 - informalsystems#233 My sense is that, if we want to set a strict abci version requirement for the rpc client, then we should put that in the source code itself. E.g., we might put a check on the client that ensures the abci version is within a specified version range known to be supported. If the version is outside that range, we could either error out or log errors/warning to alert users that we don't guarantee compatibility. However, the current approach of hardcoding in a version in the integration test seems to create a lot of busy work due to uninformative test failures and it's not obvious what value it delivers. If the integration tests are meant to test that the RPC client integrates correctly with ACBI, should we really consider integration to have failed when everything works as expected while interfacing with an older (or newer) version? Signed-off-by: Shon Feder <shon@informal.systems>
Signed-off-by: Shon Feder <shon@informal.systems>
e2c444a
to
ec50545
Compare
Yeah I think we want to fail the build if the integration tests do not pass on stable. Great job by the way, thanks a lot! |
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 @shonfeder !!!
I'm surprised the integration tests still fail despite fixing the version to 0.33.5 🤔 maybe there were some changes we missed in the meantime. |
I have not. Other than env variables I can't think of anything right now but will think about it for a bit and geet back to you.
This may have something to do with our new lib for encoding json to replace amino. |
Merging as is. I'll investigate why the tests are failing in a separate pr later. |
This is actually because the tests against From the introductory comment:
Yes, I think that would be OK for now! Please do (or anyone else with necessary perms) |
Closes #304
With this change, CI runs two integration tests:
stable
test to protect against regressions, run against a pinnedversion of the tendermint/tendermint docker image.
latest
test to track whether we're maintaining parity with thelatest development version of tendermint-go.
IIUC, we'd ideally like (1) to be a required test, and to get visibility on (2) but not block the PR if it fails. I can configure (2) so that it the job succeeds even if the step fails, but then we lose clear visibility on the failure.
Please see individual commits for more detail.