action #174451
openQA (public) - coordination #162890: [saga][epic] feature discoverability
coordination #162896: [epic] Job triggering on jobless openQA instances
openQA-in-openQA tests can get stuck with an inconsistent repository size:S
0%
Description
Observation¶
After #167395 openQA-in-openQA tests use devel:openQA:testing
which is a snapshot of devel:openQA
created before triggering tests. Unfortunately this snapshot can be created at a bad time where the repository is inconsistent. At least that's how it looks like on https://openqa.opensuse.org/tests/4704845#step/openqa_worker/1 where the installation of openQA-worker
fails with The to be installed openQA-worker-4.6.17… requires 'openqa-common = 4.6.17…
… but this requirement cannot be provided. Then it suggests do downgrade to packages from openSUSE.
The tests retries the installation but because devel:openQA:testing
is snapshotted after #167395 this is in vain now.
I checked the video and it looks like the test really only adds devel:openQA:testing
(and not e.g. devel:openQA
in addition). So I think an inconsistent snapshot of devel:openQA:testing
is the most likely explanation.
Acceptance criteria¶
- AC1: Tests are only triggered from a consistent snapshot of
devel:openQA
Suggestions¶
- Familiarize yourself with https://github.com/os-autoinst/scripts/blob/master/trigger-openqa_in_openqa and https://github.com/os-autoinst/scripts/blob/master/os-autoinst-obs-auto-submit and http://jenkins.qa.suse.de/job/submit-openQA-TW-to-oS_Fctry/ to understand the current pipeline and the involved scripts / #167395
- Ensure that the repository
devel:openQA
is "consistent" (supposedly everything is in the published state) before "releasing" it ondevel:openQA:testing
. - After the releasing has been done, check whether a consistent state has been released. (All split packages have the same version.)
- Ask on OBS channels about this problem of the release command and how it is usually dealt with.