QA » openQA Project » openQA Tests » ALP

The staging schedule for slem -> https://gitlab.suse.de/openqa/openqa-trigger-from-ibs-plugin/-/blob/master/xml/SUSE%3ASLE-15%3ASLEMicro%3AStaging.xml

Ok, let's do this. Martin pointed me to https://github.com/os-autoinst/openqa-trigger-from-obs

I've added the ALP Staging job group on openqa.opensuse.org

I'm wondering how much sense it makes to have a Staging project in openQA, when there are no images in the ALP Staging project on OBS

There is now a first set of images in Staging for ALP:

https://download.opensuse.org/repositories/SUSE:/ALP:/Staging:/B/images/

expect Staging A too soon

Finally managed to re-draft the PR https://github.com/os-autoinst/openqa-trigger-from-obs/pull/183 that should use Statging:[A-Z] from OBS.

I also updated the Medium type to alp 0.1 Staging-kvm x86_64 and the ALP Staging job template in o3.

https://github.com/os-autoinst/openqa-trigger-from-obs/pull/183 is up for review and merge.

Suggestion for fixing the failing ansible tests: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15814

I'm wondering why there is no new openQA test run for the ALP 22.3 image from Staging A or Staging B. We merged SUSE:ALP:Staging.xml but on openqa.opensuse.org ALP Staging there is only the 22.1 build that I triggered manually.

Habemus Staging image test runs: https://openqa.opensuse.org/group_overview/105

Adding ALP Staging to the opensuse-job definitions: https://github.com/os-autoinst/opensuse-jobgroups/pull/221

those staging image still uses the "hardcoded" repository in the image (which is why there is a test failure). Test should be adapted to use the associated repository at https://download.opensuse.org/repositories/SUSE:/ALP:/Staging:/A/images/repo/ALP-0.1-x86_64-Media1/ instead.

We're having two issues in those test runs, take e.g. https://openqa.opensuse.org/tests/2877129

cockpit-service fails with https://openqa.opensuse.org/tests/2877129#step/cockpit_service/14

Problem: the to be installed cockpit-machines-270.2-6.3.noarch requires 'virt-install', but this requirement cannot be provided
  not installable providers: virt-install-4.1.0-3.1.noarch[ALP]
                   virt-install-4.1.0-3.2.noarch[ALP-Build]
                   virt-install-4.1.0-3.4.noarch[ALP-Build]
 Solution 1: install python310-base-3.10.8-8.2.x86_64 from vendor obs://build.opensuse.org/SUSE:ALP:Rings
  replacing python310-base-3.10.7-7.1.x86_64 from vendor obs://build.opensuse.org/SUSE:ALP:Staging
 Solution 2: do not install cockpit-machines-270.2-6.3.noarch
 Solution 3: break cockpit-machines-270.2-6.3.noarch by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): 

And ansible is also not happy: https://openqa.opensuse.org/tests/2877129#step/ansible/36

transactional-update -n pkg install ansible git-core sudo > /dev/ttyS0; echo trup-$?- | tee -a /dev/ttyS0
ERROR: zypper install on /.snapshots/4/snapshot failed with exit code 4!
Use '--interactive' for manual problem resolution.
Removing snapshot #4...

fcrozat wrote:

those staging image still uses the "hardcoded" repository in the image (which is why there is a test failure). Test should be adapted to use the associated repository at https://download.opensuse.org/repositories/SUSE:/ALP:/Staging:/A/images/repo/ALP-0.1-x86_64-Media1/ instead.

Yes, this is likely the source for the above stated error messages. Thank you Frederic!

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15915

Whitelist the journal test runs: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15925