QA (public) - coordination #99303: [saga][epic] Future improvements for SUSE Maintenance QA workflows with fully automated testing, approval and release
QA (public) - action #97274: qam dashboard improvement ideas
Added by okurz over 3 years ago. Updated about 3 years ago.
Description
Added to backlog as discussed during midweekly unblock meeting within SUSE QE Tools 2021-11-10 as we covered this topic. kraih wanted to volunteer for #94838 and this is closely related.
#94838 was successfully completed. With that approach we managed to still run gitlab CI pipelines. We can either follow the same approach for bot-ng or similar as we do for https://github.com/os-autoinst/openqa_review along with https://gitlab.suse.de/openqa/openqa-review/
I am ready to take this myself then. IMHO for creating a project on github we should think about a good name. "bot-ng" itself is ambiguous so a project like https://github.com/openSUSE/bot-ng wouldn't be a good idea. This is why I always consider the full name to be "qa-maintenance/bot-ng". How about "qambot"? A one-line explanation describing the project could then be "The SUSE QA Maintenance bot for openQA". For a complete project name I suggest "https://github.com/openSUSE/qambot" and as alternative "https://github.com/os-autoinst/qambot". Any opinions?
Regarding deployment we are currently using gitlab CI with periodic schedule based executions within the gitlab CI pipelines based on container images. So in my understanding we can simply exchange the container image to use one from build.opensuse.org including SUSE CA certificates, e.g. just like build.opensuse.org/project/show/home:okurz:container:ca/ and use the latest container images in each execution cycle so there is no impact where the code is maintained.
Asked in weekly unblock of the team. We decided that we favor https://github.com/openSUSE/qem-bot as a name.
Created empty repo https://github.com/openSUSE/qem-bot and will use the same approach as in #90164 first to mirror the data, then we can softly switch over CI pipelines and test it out before we remove the source from the internal repo. So I created the new github repo, invited the openSUSE/tools-team and "openqa-git-sync". I logged into that account in my browser in a private window using credentials from https://gitlab.suse.de/openqa/scripts/-/blob/master/password#L18, copied the invitation URL received by email into that browser instance and accepted the invitation. In https://gitlab.suse.de/qa-maintenance/bot-ng/-/settings/repository I added the URL https://openqa-git-sync@github.com/openSUSE/qem-bot with the according password. I triggered an update run and https://github.com/openSUSE/qem-bot has it all. Currently the CI pipeline in https://gitlab.suse.de/qa-maintenance/bot-ng/-/blob/master/.gitlab-ci.yml#L12 uses registry.suse.de/qa/maintenance/containers/qam-ci-leap:latest which comes from https://build.suse.de/package/view_file/QA:Maintenance/openSUSE-Leap-Container/Dockerfile?expand=1 . The only internal package in there seems to be https://build.suse.de/package/show/QA:Maintenance/qam-metadata . But it seems we only bring in the metadata this way and dependencies. The source code of qem-bot itself so far we cloned in the pipeline from the git repo itself. I propose to change that with https://gitlab.suse.de/qa-maintenance/bot-ng/-/merge_requests/48 to use the github repo directly.
waiting for merge of MR before disabling mirorring again and moving and removing internal source and just keeping the gitlab CI config.
mirroring was disabled and https://gitlab.suse.de/qa-maintenance/bot-ng/-/commit/c2fbf9443c6c7f3a5560d2a7644d2704ed35c40f removed the source except the gitlab CI pipeline config. So this is done as well