QA » openQA Project

Note that factory does not accept _services - so would you need to register what git version actually was tested and submit that explicitly by regenerating the tar

so checkout package locally, repack, submit to devel:openQA:testing and submit from there?

yes, if you want to submit it, you have to fork off before testing

https://bugzilla.suse.com/show_bug.cgi?id=1032649 is RESOLVED FIXED but was until very recently waiting for https://build.opensuse.org/request/show/491831 to be resolved to have updated RPM check scripts. The SR got accepted 4 days ago, potentially it needs a bit of time until it's active on the side of Factory submission checks.

In the meantime I patched the spec files within :tested to not install the dbus services part to give legal checking a chance. So two new SRs exist

• os-autoinst already accepted
• openQA in review

after these got accepted I can put the automatic submissions based on test results in place to update the existing packages.

both SR accepted, os-autoinst+openQA are in openSUSE Factory now \o/

next step: re-enable dbus part in spec file, then automatic submissions

https://build.opensuse.org/request/show/491831 was accepted 6 days ago. It does not seem to have an effect so far -> https://build.opensuse.org/request/show/494326 . any way to check version of rpmlint installed or something? I could only find rpmlint-mini and rpmlint-Factory in the build log
[10 May 2017 17:08:47] <|Anna|> sr#491831 [submit devel:openSUSE:Factory:rpmlint/rpmlint -> openSUSE:Factory/rpmlint] - whitelisting backintime (https://bugzilla.suse.com/1007723, https://bugzilla.suse.com/1032717) (forwarded request 49... (State: accepted) -- https://build.opensuse.org/request/show/491831
[10 May 2017 17:08:48] <|Anna|> sr#494326 [submit devel:openQA:tested/os-autoinst -> openSUSE:Factory/os-autoinst] Update including re-enabled dbus service installation (State: declined) -- https://build.opensuse.org/request/show/494326

rpmlint is in Factory now, os-autoinst builds and passes rpmlint check with enabled dbus. maxlin built with nogroup fix however there is another new dbus packaged https://build.opensuse.org/package/show/home:mlin7442:branches:devel:openQA:tested/openQA
I created a request for security audit: https://bugzilla.suse.com/show_bug.cgi?id=1039290

os-autoinst is in openSUSE:Factory but I would like to wait for the updated package of openQA before adding automatic submissions to prevent os-autoinst+openQA being out-of-sync and having incompatible versions.

waiting for https://build.opensuse.org/request/show/500158 reg. security audit of openQA dbus service

accepted with https://build.opensuse.org/request/show/500576, bug 1039290 VERIFIED FIXED, openQA with enabled dbus service is now in openSUSE Factory -> https://build.opensuse.org/request/show/503557

https://build.opensuse.org/request/show/504232 should bring devel:openQA/openQA in line with devel:openQA:tested/openQA, next step can be automatic submissions to openSUSE Factory then.

In the meantime, submitting to openSUSE Leap 42.3 needs sr#504635 and sr#504637 first for updated dependencies

https://build.opensuse.org/request/show/504915 to bring devel:openQA/openQA in sync with devel:openQA:tested/openQA accepted. Also accepted for Leap 42.3:

• https://build.opensuse.org/request/show/503610
• https://build.opensuse.org/request/show/504636
• https://build.opensuse.org/request/show/504637

so os-autoinst and openQA is in openSUSE Leap 42.3 \o/

so now for the automatic submissions :-)

So far there have been some automatic SRs, nobody complained. Submissions to openSUSE Leap 15.0 also happen automatically after the initial manual one. Now as our main production workers run stable version of openSUSE Leap the maintenance updates would need to be done automatically as well. astieger would be ok with say one submission per week but I'm not sure if this is responsive enough. Maybe just trigger the automatic updates on o3 and osd from devel:openQA:tested whenever the openQA-in-openQA tests succeed?

We won't deploy updates automatically, no

coolo wrote:

We won't deploy updates automatically, no

Well, that problem had been solved by rbrownsuse at least for o3 workers with changing the setup to "transactional-update" systems ;)

What do you think of "one-click-deployments" like in https://gitlab.suse.de/okurz/osd-deployment/-/jobs/54944 including automatic email notification of deployed changes?

What changed since #18006#note-19¶

• o3 workers are based on openSUSE Leap 15.0 transactional server setup by rbrown with automatic nightly deployment from devel:openQA
• o3 webui is not automatically updated but regularly about once a week by me

Proposal¶

• move the existing jenkins jobs into a gitlab CI pipeline (see #18006#note-22)
• as in before create the SR to openSUSE Factory but in parallel submit from devel:openQA:tested to devel:openQA:stable
• configure our workers to install from devel:openQA:stable instead of devel:openQA
• optional: Extend the automatic tests to test on openSUSE Leap 42.3 base as well, not only Tumbleweed
• configure the webui host to also install from devel:openQA:stable and do that as part of our gitlab CI pipeline automatically

discussed with nsinger, we can try out the gitlab pipeline approach this Wednesday for OSD.

side-note: I wonder why we store https://build.opensuse.org/package/show/devel:openQA:tested/update on OBS and not a git repo, could be more accessible for others e.g. for other packages to use as a template.

I do not recall any good reason to try to manage the single script _update.sh in OBS when we have even moved the spec files to the upstream github projects hence in #54467 I proposed to create https://github.com/os-autoinst/scripts which I finally did. So therefore I proposed https://github.com/os-autoinst/scripts/pull/3 with the monitor+trigger scripts added along with the automatic submission script in https://github.com/os-autoinst/scripts/pull/2 to bring these components together. This could even allow us to use external CIs like the CI on gitlab.com or travis CI or circle CI or whatever instead of relying on an internal jenkins instance.

both PRs merged. https://gitlab.suse.de/openqa/scripts/merge_requests/376 created to propose the deletion of the openqa-in-openqa scripts from https://gitlab.suse.de/openqa/scripts/ as they now live in https://github.com/os-autoinst/scripts . Updated the description on https://build.opensuse.org/package/show/devel:openQA:tested/update to mark it as OBSOLETE with a link to https://github.com/os-autoinst/scripts/blob/master/os-autoinst-obs-auto-submit instead but have not yet deleted it.

For automatic installs of the openQA webUI I am thinking of checking:

result="$(curl -s "https://api.opensuse.org/public/build/devel:openQA/_result?repository=openSUSE_Leap_15.1&arch=x86_64")"
echo -e "$result" | grep -q 'project.*state="published"'
echo "$result" | grep 'status package' | (! grep -v '\(disabled\|succeeded\|excluded\)')

during a nightly window. This should also cover neighboring packages, e.g. openQA-test. TODO how to handle that in a cron job, e.g. wait for X retries until package is published and fine?

I wonder why we proposed devel:openQA:tested and not devel:openQA:testing when the package are not yet tested when they enter that project? I am thinking about a subproject to put packages to after they actually got tested
Would it be a good idea to have a subproject with actually tested packages to auto-install from? or should I just wait for AMQP events from OBS telling me that all packages are successfully published to trigger an install? or a gitlab CI pipeline?

Let's try the easy/ugly way. on o3:

cat /etc/cron.d/auto-update
# https://progress.opensuse.org/issues/18006
0 3 * * 0 root result="$(curl -s "https://api.opensuse.org/public/build/devel:openQA/_result?repository=openSUSE_Leap_15.1&arch=x86_64")" && echo -e "$result" | grep -q 'project.*state="published"' && echo "$result" | grep 'status package' | (! grep -v '\(disabled\|succeeded\|excluded\)') && zypper -n dup --replacefiles --auto-agree-with-licenses --force-resolution --download-in-advance

how to handle that in a cron job, e.g. wait for X retries until package is published and fine?

What happens if the cron jobsystemd timer, which is hosted in git, fails after X attempts? Do we get an email/ notification?

Some thoughts on the one-click deployment, after having been the substitute deployment lead:

• The manual steps involve these assets, which we probably want to retain
  • A backup
  • Versions from before and after
  • Install logs - We'd obviously get logs from the whole process, but it might be nice to save it explicitly for convenience
  • Generating a changelog
  • Updating the deployment page
  • Sending an email with the deployment
• Would we want to have separate worker and webui jobs? Case in point, poo#11706 benefits from deploying workers before webui