test fails in test_running
openQA test in scenario openqa-Tumbleweed-dev-x86_64-openqa_install+publish@64bit-2G fails in
Test suite description¶
Maintainer: email@example.com 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.
Fails since (at least) Build :TW.12917 (current job)
Last good: :TW.12916 (or more recent)
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
#3 Updated by okurz about 2 months ago
[warn] Unable to determine worker address (WORKER_HOSTNAME) - checking again for web UI 'localhost' in 20.00 s
#5 Updated by mkittler about 2 months 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).
#7 Updated by mkittler about 2 months ago
- Status changed from New to In Progress