-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
e2e: show command and output when a timeout happens #15021
e2e: show command and output when a timeout happens #15021
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Luap99 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
That was the first thing I tried yesterday (except for the Unfortunately, in my testing, it appears that the right-hand side is evaluated at call time, not fail time, therefore stdout and stderr are blank. I ended up solving it by using a loop (this did not seem like thread-critical code) and that actually worked in my testing but does not give anything useful in the containerized-checkpoint test timeouts. Possibly I need to Anyhow, try testing this by running a podman command like |
To make debugging easier we should see the command and its output when a failure happens. Signed-off-by: Paul Holzinger <[email protected]>
5dc2e80
to
3a016c6
Compare
@edsantiago Ok I tried this locally and now it should work, we have to change it to a function |
Test output:
|
Tests are green. I like this better than your fix, @edsantiago WDYT? |
This is 1E6 times better than mine, thank you! One quibble: I would prefer: - Command %v timed out
+ Command timed out after %ds: %v (i.e., include timeout value, and show command after, not before, to make 'Command timed out' a searchable in-page string). I'm happy to merge this now and address those changes in my neverending #14972 if that's OK with you. Feel free to unhold but continue discussion here. /lgtm |
/hold cancel Fell free to make those changes in your PR |
...and enable the at-test-time confirmation, the one that double-checks that if CI requests runc we actually use runc. This exposed a nasty surprise in our setup: there are steps to define $OCI_RUNTIME, but that's actually a total fakeout! OCI_RUNTIME is used only in e2e tests, it has no effect whatsoever on actual podman itself as invoked via command line such as in system tests. Solution: use containers.conf Given how fragile all this runtime stuff is, I've also added new tests (e2e and system) that will check $CI_DESIRED_RUNTIME. Image source: containers/automation_images#146 Since we haven't actually been testing with runc, we need to fix a few tests: - handle an error-message change (make it work in both crun and runc) - skip one system test, "survive service stop", that doesn't work with runc and I don't think we care. ...and skip a bunch, filing issues for each: - containers#15013 pod create --share-parent - containers#15014 timeout in dd - containers#15015 checkpoint tests time out under $CONTAINER - containers#15017 networking timeout with registry - containers#15018 restore --pod gripes about missing --pod - containers#15025 run --uidmap broken - containers#15027 pod inspect cgrouppath broken - ...and a bunch more ("podman pause") that probably don't even merit filing an issue. Also, use /dev/urandom in one test (was: /dev/random) because the test is timing out and /dev/urandom does not block. (But the test is still timing out anyway, even with this change) Also, as part of the VM switch we are now using go 1.18 (up from 1.17) and this broke the gitlab tests. Thanks to @Luap99 for a quick fix. Also, slight tweak to containers#15021: include the timeout value, and reword message so command string is at end. Also, fixed a misspelling in a test name. Fixes: containers#14833 Signed-off-by: Ed Santiago <[email protected]>
To make debugging easier we should see the command and its output when a
failure happens.
Does this PR introduce a user-facing change?