QA » openQA Project

We could do the following:

1. Save the current revision of the set of packages (auto_submit_packages=${packages:-$($osc ls "$dst_project" | grep -v '\-test$')}) via e.g. osc log devel:openQA openQA | grep/sed/… in trigger-openqa_in_openqa like we already save job_post_response.
2. Submit that revision via osc -r $rev co in os-autoinst-obs-auto-submit. We need to use the same approach for copying artifacts as in monitor-openQA_in_openQA-TW.

The problem with this is that the revision saved in 1. might not be the revision we have actually tested. Until the test is scheduled and reaches the point where packages are installed from OBS a new version might have been published on OBS.

It would probably make more sense if we do the following:

1. Keep the triggering as-is.
2. Upload the exact package versions that were installed during the test run.
3. Download the log from 2. in scripts/os-autoinst-obs-auto-submit. For this we need to know the job IDs be we have it in job_post_response and just need to restore them like in monitor-openQA_in_openQA-TW.
4. Check whether that version matches what we still have on OBS. If not, either skip the submission or try to figure out what revision had this version and submit that via osc -r $rev co.

Note that step 2 makes actually only sense for the scenarios that install packages from OBS. So within the set of jobs that we start only some jobs will contain the information about the package versions. This is presumably ok. Considering that there are multiple scenarios that install from OBS there can actually be the case when those tests did not all run on the same version of every package. Maybe we should then in step 4 simply reject the whole submission (will hopefully not happen very often).

We discussed that it would be better to look into the "branching" alternative (mentioned as 2nd suggestion in the ticket description).

So I invoked to create a "fixed" copy of some packages in our devel:openQA project under devel:openQA:testing¹:

osc linkpac --current --disable-build devel:openQA os-autoinst devel:openQA:testing
osc linkpac --current --disable-build devel:openQA openQA devel:openQA:testing

It looks like --disable-build simply sets the build flag in the config of the package to false. The publish flag is still true, though.

Unfortunately this kind of setup doesn't work. OBS says "Repository has been published" but https://download.opensuse.org/repositories/devel:/openQA:/testing/openSUSE_Tumbleweed has not been populated so far.

So also I tried:

osc branch --force --disable-build devel:openQA openQA devel:openQA:testing

But the repo is still not populated.

I guess I'll have to research how this can be done or ask for help. We could of course also download the repo manually and serve it via some HTTP server outside the scope of OBS.

EDIT: Asked on Slack: https://suse.slack.com/archives/C02BXKBMXNV/p1731605574673919

¹ Probably we should create and delete this project on the fly. The trigger script would delete it when not already there and otherwise abort. The monitoring/submission script would delete the project when done. This way the presence of the project would act as a flag to know whether testing/submissions are still pending (and be able to avoid triggering new tests/submissions if there is still one pending).

It turns out that one needs to use osc release for this (thanks to @bmwiedemann pointing this out to me).

So the following does the trick:

for package in os-autoinst openQA; do osc release --target-project devel:openQA:testing --no-delay --target-repository=openSUSE_Tumbleweed -r openSUSE_Tumbleweed -a x86_64 devel:openQA "$package"; done

This command populated https://download.opensuse.org/repositories/devel:/openQA:/testing/openSUSE_Tumbleweed/x86_64/ with no delay (so I suppose --no-delay works as advertised).

PR for being able to use the snapshot project in openQA-in-openQA tests: https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/215