Mentat

From discussion with Martin Dušička:

• There are 4 runners for general use directly on GitLab server
• GitLab Pages not working yet, Martin has to decide where (and how) to make them accessible
  • Pages would allow to publish docs and probably repos
• Wiki will be migrated as is, we will cleanup later (so we will have history on GitLab)

Question is how to manage PGP keys for deb package signing. Possibilities (already sorted by viability):

1. Extra repo with keyring and limited access (can be common for more projects, we don't mind binary contents as it gets changed rarely and never edited by hand)
2. Private and public key in GitLab variables (signing script must always reinitialize all new keyring, must be in variables in every project concerned)
3. Docker image with ready keyring (problem of encrypted contents on public place or need to keep own image resource, cumbersome and nonversioned updates of the keyring)

First one seems plausible.

Wouldn't it make sense to make our own and push it to the hub? Seems creating Docker images based on pre-existing ones needs might need just short Dockerfile.

https://linuxhint.com/automatically-build-docker-images-in-debian-10-buster/

Rajmund Hruska wrote in #note-13:

I lost my notes from the meeting where we discussed this issue. So, I should create a job which downloads all the files at a given URL address? If I remember correctly, we want to get the older files from https://alchemist.cesnet.cz/pyzenkit/files/development/ and also have some kind of backup if we lose data from GitLab.

We wanted to solve two main problems:

• Loss of continuity – something in Gitlab goes awry or human makes an error, and we thus lose the continually reloaded artifact containing older releases
• Migration of older data from Redmine

If memory serves me well (sorry, too much parity errors these days), we came to rather simple sidestep – define GitLab variable, which, if set to a bunch of URLs, would cause build script to download contents of all the URLs and populate the "history" artifact (or maybe one URL with expected zipfile? Just what's simpler). That would allow to inject initial history (from Redmine), which we are not able to reconstruct, and also to possibly inject history from backups if data end up in a blue smoke.

Also, we should actively backup those released files, for example by regular download to backed tree at Mentat-alt or somewhere.

Pavel Kácha wrote in #note-14:

Also, we should actively backup those released files, for example by regular download to backed tree at Mentat-alt or somewhere.

So, the backup is set up on mentat-alt. If I understand it correctly I can keep the built packages in /var/backups/ .

Rajmund Hruska wrote in #note-15:

So, the backup is set up on mentat-alt. If I understand it correctly I can keep the built packages in /var/backups/ .

Yup, or some convenient subdirectory thereof.

From 2023-06-22 meeting:

• GitLab expects specific suffixes as a part of version.
• GitLab extracts version of the package from the changelog.

Our old packages (generated on Buildbot) don't satisfy neither GitLab requirement - although we have the mechanism to upload old packages along with new generated ones, packages are in wrong branch with wrong (all the same) fabricated version.

To add insult to injury, our deb packages are de facto envelope around venv and pip install, and keep static URL to the Buildbot.

Conclusion - attempts to incorporate old packages onto GitLab along with new ones would take too much effort with inadequate results. Let's not try unify old and new packages and let's keep URL to Buildbot on the web as obsolete and keep running Buildbot (maybe without Alchemist) for some time (a year maybe?). And then ditch it altogether.

mentat-alt is now installed and upgraded from GitLab packages. There is no need to push to buildbot/alchemist anymore.

🎆 👏 🥂