action #121567
closedtest fails in test_running
Description
Observation¶
openQA test in scenario openqa-Tumbleweed-dev-x86_64-openqa_install+publish@64bit-2G fails in
test_running
Test suite description¶
Maintainer: okurz@suse.de Test for installation of openQA itself. To be used with "openqa" distri. Publishes an qcow2 image including the openQA installation ready to run as an appliance.
Reproducible¶
Fails since (at least) Build :TW.12917 (current job)
Expected result¶
Last good: :TW.12916 (or more recent)
Further details¶
Always latest result in this scenario: latest
Looking at the video and in the log retry doesn't seem to do any retries:
[2022-12-06T12:02:51.501219+01:00] [debug] <<< testapi::assert_script_run(cmd="retry -s 30 -r 5 -- openqa-cli api jobs state=running state=done | ack --passthru --color \"running|done\"", fail_message="", timeout=300, quiet=undef)
...
[2022-12-06T12:02:58.353973+01:00] [info] ::: basetest::runtest: # Test died: command 'retry [...]
That's only 7 seconds.
I guess that's because the openqa-cli command passes, and the ack fails, but the retry is attached to the openqa-cli command.
Possibly related: https://github.com/os-autoinst/openQA/pull/4935 Avoid running jobs with undetermined worker address
Updated by okurz almost 2 years ago
- Related to action #120261: tests should try to access worker by WORKER_HOSTNAME FQDN but sometimes get 'worker2' or something auto_review:".*curl.*worker\d+:.*failed at.*":retry size:meow added
Updated by okurz almost 2 years ago
https://openqa.opensuse.org/tests/2931073#step/test_running/11 states
[warn] Unable to determine worker address (WORKER_HOSTNAME) - checking again for web UI 'localhost' in 20.00 s
Updated by mkittler almost 2 years ago
Looks like the worker cannot determine WORKER_HOSTNAME in this test environment. That it then refuses to run jobs (until the problem is fixed) is actually a feature and not a bug. I suppose we can simply set WORKER_HOSTNAME here explicitly (e.g. even to 127.0.0.1 to make it clear that this worker isn't meant to be reached from the outside).
Updated by mkittler almost 2 years ago
- Status changed from New to In Progress
Updated by openqa_review almost 2 years ago
- Due date set to 2022-12-21
Setting due date based on mean cycle time of SUSE QE Tools
Updated by mkittler almost 2 years ago
- Status changed from In Progress to Feedback
I ended up creating a 3rd PR (and closing the other ones): https://github.com/os-autoinst/openQA/pull/4949
It has been merged. Let's see whether that fixes the openQA-in-openQA test.
Updated by okurz almost 2 years ago
- Status changed from Feedback to Resolved
https://openqa.opensuse.org/tests/2935168 is good again. Thank you