Fix the smoke tests #11844
Merged
Fix the smoke tests #11844
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The `make go-build` has changed from 2.7 to 2.8 and the smoke tests previously checked if there was any output. Now we check for if the command was successful. As we need to use the `$?` pattern a lot I've added it to the SHELLCHECK_OPTS.
achilleasa
reviewed
Jul 20, 2020
Additionally we need to see output from some commands to help diagnose issues. You can do this with the switch statement. I'm currently unsure about keeping VERBOSE 3 level, as it's so chatty nobody can tell what's going on... we really need to re-think that part.
SimonRichardson
commented
Jul 20, 2020
SimonRichardson
commented
Jul 20, 2020
| echo "\\n${OUT}" | ||
| exit 1 | ||
| fi | ||
| make go-build 2>&1 |
There was a problem hiding this comment.
Rather than be fancy, just let it fail!
There was a problem hiding this comment.
if you still want to be fancy:
OUT=$(make go-build 2>&1 || echo "BUILD FAILED")
if [ "$OUT" =~ (BUILD FAILED) ]; then
....
fi
There was a problem hiding this comment.
I'll think about it
achilleasa
reviewed
Jul 20, 2020
The following updates the output from the integration tests to be much more simplistic. There are now only two modes, the very terse mode, which is great to just see from a very high level overview if something works or broke: ./main.sh smoke Or using the verbose mode that aims to be chatty, but not overly chatty like with the use of `set -eux`. The `x` part makes it hard to see what's happening and should be only used for local debugging. ./main.sh -v smoke With this simplistic model we should be able to see what's failing within jenkins, as we use `-v` as the default mode for all our testing.
achilleasa
approved these changes
Jul 20, 2020
| fi | ||
|
|
||
| while read data; do | ||
| if [ -z "${output}" ]; then |
There was a problem hiding this comment.
It did take me a while to figure out what the various if blocks do here. It would be great if you could add some comments for others examining this part of the code in the future.
The output function is a bit cryptic, so I've added some comments to help understand that. The output function aims to solve all the outputing issues from running commands against juju.
|
|
1 similar comment
|
|
jujubot
added a commit
that referenced
this pull request
Jul 22, 2020
#11852 Zero-conflict merge from 2.8 to bring forward: - #11851 from manadart/2.8-remove-lld-refcount - #11846 from howbazaar/2.8-watch-models-application-status - #11840 from ycliuhw/fix/lp-1875481 - #11845 from ycliuhw/fix/lp-1883006 - #11844 from SimonRichardson/fix-smoke-tests - #11837 from tlm/pod-spec-json
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of change
The
make go-buildhas changed from 2.7 to 2.8 and the smoke testspreviously checked if there was any output.
The following updates the output from the integration tests to be much
more simplistic. There are now only two modes, the very terse mode,
which is great to just see from a very high-level overview if something
works or broke:
Or using the verbose mode that aims to be chatty, but not overly chatty
like with the use of
set -eux. Thexpart makes it hard to seewhat's happening and should be only used for local debugging.
With this simplistic model, we should be able to see what's failing
within jenkins, as we use
-vas the default mode for all our testing.QA steps