QA

okurz wrote:

can you just share for our readers a little bit more how the current setup looks like please :)

The dashboard is a "classical web application" so (apart from job-oriented bot-ng) it requires a place where it can run continuously. It also requires a database for some transient data and (optionally) a HTTP proxy to handle extra stuff like HTTPS termination (although that can be managed by the application itself). As there already were some QAM-related stuff running on the qam2.suse.de, it was a clear choice at that time. To lower the complexity for future server upgrades, most of the services there were deployed in independent containers with only host network in between (the connection outside was NAT-ed by the host).

The bot-ng was moved (as result of #96998) into a Gitlab pipeline as it does not require to run all the time (it was basically a cron job in the old setup). It does need to communicate with the dashboard API to be able to work.

The current deployment (after we moved the code to the GitHub) still runs from the GitLab pipeline. We have a scheduled job there which just invokes another pipeline from qa-maintenance/qamops repository. There is a parameter PLAYBOOK which contains path to an Ansible playbook with the deployment tasks. The Ansible connects to the qam2.suse.de, ensures user/group presence, required directory structure, creates systemd service files and check outs the code from the git repository. If there were any changes it will also restart the service. It is entirely possible to also include database configuration and secrets (secrets are encrypted by ansible-vault, the password to decrypt is known by the pipeline)