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

test: Only call Fail() once for all error logs #11184

Merged
merged 1 commit into from Apr 28, 2020

Conversation

joestringer
Copy link
Member

We've recently expanded the fail cases for when different logs are seen
in the cilium-agent logs. However at the same time we also introduced
a behaviour where for every single instance of the failure in the logs,
we will call Fail(). In local CI runs with --holdEnvironment this can
lead to a loop where the test is suspended for debugging, the developer
performs ^Z and fg, then the same failure prints again, potentially
many times over before the test can finally proceed / clean up.

Tidy it up by detecting any failure of this sort once, then failing out.

Note that the actual failure logs should already be visible earlier in
the test output so this should not hide the failures from the developer.

We've recently expanded the fail cases for when different logs are seen
in the cilium-agent logs. However at the same time we also introduced
a behaviour where for every single instance of the failure in the logs,
we will call Fail(). In local CI runs with `--holdEnvironment` this can
lead to a loop where the test is suspended for debugging, the developer
performs ^Z and `fg`, then the same failure prints again, potentially
many times over before the test can finally proceed / clean up.

Tidy it up by detecting any failure of this sort once, then failing out.

Note that the actual failure logs should already be visible earlier in
the test output so this should not hide the failures from the developer.

Signed-off-by: Joe Stringer <joe@cilium.io>
@joestringer joestringer added area/CI Continuous Integration testing issue or flake release-note/misc This PR makes changes that have no direct user impact. labels Apr 27, 2020
@joestringer joestringer requested a review from a team as a code owner April 27, 2020 23:45
@maintainer-s-little-helper maintainer-s-little-helper bot added this to In progress in 1.8.0 Apr 27, 2020
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.02%) to 44.779% when pulling 81aaa44 on joestringer:submit/fix-ci-logs-check into e7d4f5c on cilium:master.

@joestringer
Copy link
Member Author

joestringer commented Apr 28, 2020

test-me-please

EDIT: CI:

18:15:24 runtime: received unexpected HTTP status: 500 Internal Server Error

18:18:49 runtime: Error response from daemon: Get https://quay.io/v2/cilium/cilium-builder/manifests/2020-04-16: received unexpected HTTP status: 500 Internal Server Error

Looks like bad luck with quay.io outage. Will re-try.

@joestringer
Copy link
Member Author

test-me-please

Copy link
Member

@pchaigno pchaigno left a comment

Choose a reason for hiding this comment

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

Thanks for fixing this! One less item on my todo list :-)

Note that the actual failure logs should already be visible earlier in
the test output so this should not hide the failures from the developer.

Are you referring to the Top 5 errors/warnings? Apart from that top 5 (and only if they are frequent enough), I don't think bad log messages are printed on test failures. You have to dig through the logs to find them, no?

@tgraf tgraf merged commit a4867b8 into cilium:master Apr 28, 2020
1.8.0 automation moved this from In progress to Merged Apr 28, 2020
@joestringer
Copy link
Member Author

Are you referring to the Top 5 errors/warnings? Apart from that top 5 (and only if they are frequent enough), I don't think bad log messages are printed on test failures. You have to dig through the logs to find them, no?

At least locally I found that they were printed twice in the output. It's possible that one goes to stdout and the other goes to the ginkgoprinter. If the representation is not obvious in the jenkins side output then we may need to just make sure we direct that output to the correct writer (might be a matter of just adding an extra log printing statement to the previous fail location).

@joestringer joestringer deleted the submit/fix-ci-logs-check branch April 28, 2020 15:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/CI Continuous Integration testing issue or flake release-note/misc This PR makes changes that have no direct user impact.
Projects
No open projects
1.8.0
  
Merged
Development

Successfully merging this pull request may close these issues.

None yet

4 participants