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 integration test pinned to tendermint-go v0.33.5 #324

Merged

Conversation

shonfeder
Copy link
Contributor

@shonfeder shonfeder commented Jun 14, 2020

Closes #304

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.

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.

  • Referenced an issue explaining the need for the change
  • Updated all relevant documentation in docs
  • Updated all code comments where relevant
  • Wrote tests
  • Updated CHANGES.md

@codecov-commenter
Copy link

codecov-commenter commented Jun 14, 2020

Codecov Report

Merging #324 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

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

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 740cb66...ec50545. Read the comment docs.

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

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

@shonfeder shonfeder force-pushed the pin-integration-test-to-v0.33 branch from b452fcc to adc3101 Compare June 15, 2020 01:26
@shonfeder shonfeder changed the title WIP: Add job pinned to tendermint-go v0.33.5 Add integration test pinned to tendermint-go v0.33.5 Jun 15, 2020
@shonfeder
Copy link
Contributor Author

This change should make it possible to make the test-integration-stable test required (if that's desirable).

@@ -61,11 +61,34 @@ jobs:
command: test
args: --all-features --no-fail-fast

test-integration-ignored:
# TODO(shonfeder): remove duplication once GitHub addresses
Copy link
Contributor Author

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

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

Copy link
Member

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?

Shon Feder added 3 commits June 14, 2020 22:01
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>
@shonfeder shonfeder force-pushed the pin-integration-test-to-v0.33 branch from e2c444a to ec50545 Compare June 15, 2020 02:01
@romac
Copy link
Member

romac commented Jun 15, 2020

This change should make it possible to make the test-integration-stable test required (if that's desirable).

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!

Copy link
Member

@liamsi liamsi left a comment

Choose a reason for hiding this comment

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

Thanks @shonfeder !!!

@liamsi
Copy link
Member

liamsi commented Jun 15, 2020

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.

@tac0turtle
Copy link
Contributor

as you looked a lot more into GA, do you have a suggestion how to parameterize this?

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.

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.

This may have something to do with our new lib for encoding json to replace amino.

@liamsi
Copy link
Member

liamsi commented Jun 15, 2020

Merging as is. I'll investigate why the tests are failing in a separate pr later.

@liamsi liamsi merged commit 704e244 into informalsystems:master Jun 15, 2020
@liamsi
Copy link
Member

liamsi commented Jun 15, 2020

This may have something to do with our new lib for encoding json to replace amino.

This is actually because the tests against :latest are still running:

From the introductory comment:

I can configure (2) so that it the job succeeds even if the step fails, but then we lose clear visibility on the failure.

Yes, I think that would be OK for now! Please do (or anyone else with necessary perms)

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.

RPC integration tests failing on CI
5 participants