docker: add release images for distributions packages are generated for

[robaerd]

Part of #3716

• Adds release Docker images that can be used to try out Elektra with multiple distributions
• Fixes a problem with the release script, where if the version codename is not stated in /etc/os-release (e.g. bullseye), it could not be detected and therefore the memcheck failed. (necessary for 0.9.6 release #3824)

Basics

These points need to be fulfilled for every PR:

• Short descriptions of your changes are in the release notes
  (added as entry in doc/news/_preparation_next_release.md which
  contains _(my name)_)
  Please always add something to the release notes.
• Details of what you changed are in commit messages
  (first line should have module: short statement syntax)
• References to issues, e.g. close #X, are in the commit messages.
• The buildservers are happy. If not, fix in this order:
  • add a line in doc/news/_preparation_next_release.md
  • reformat the code with scripts/dev/reformat-all
  • make all unit tests pass
  • fix all memleaks
• The PR is rebased with current master.

If you have any troubles fulfilling these criteria, please write
about the trouble as comment in the PR. We will help you.
But we cannot accept PRs that do not fulfill the basics.

Checklist

Check relevant points but please do not remove entries.
For docu fixes, spell checking, and similar none of these points below
need to be checked.

• I added unit tests for my code
• I fully described what my PR does in the documentation
  (not in the PR description)
• I fixed all affected documentation
• I added code comments, logging, and assertions as appropriate (see Coding Guidelines)
• I updated all meta data (e.g. README.md of plugins and METADATA.ini)
• I mentioned every code not directly written by me in THIRD-PARTY-LICENSES

Review

Reviewers will usually check the following:

• Documentation is introductory, concise, good to read and describes everything what the PR does
• Examples are well chosen and understandable
• Code is conforming to our Coding Guidelines
• APIs are conforming to our Design Guidelines
• Code is consistent to our Design Decisions

Labels

If you are already Elektra developer:

• Add the "work in progress" label if you do not want the PR to be reviewed yet.
• Add the "ready to merge" label if the basics are fulfilled and you also
  say that everything is ready to be merged.

[robaerd]

@markus2330 should we also upload the "release Docker images" to Dockerhub (like we do with alpine) and tag them for example like elektra:0.9.5-1-focal, or should we only keep them in our public Docker registry (hub-public.libelektra.org)?

[markus2330]

@markus2330 should we also upload the "release Docker images" to Dockerhub (like we do with alpine) and tag them for example like elektra:0.9.5-1-focal

That would be fantastic! 🚀

or should we only keep them in our public Docker registry (hub-public.libelektra.org)?

Only if we run into upload limits. In any case, we should also have them in our registry.

[mpranj]

Thank you so much!

[mpranj]

The aptly publish steps are failing for bullseye-unstable because the repo does not exist. Are some manual steps needed to make it work? I can't find any docu how you created the other repos.

See details at:
https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/master/447/pipeline/2062/
Section "Send build artifacts over SSH"

[robaerd]

It seems you already created the missing bullseye repos?

$ aptly repo list
List of local repos:
 * [bionic-unstable] (packages: 54)
 * [bionic] (packages: 49)
 * [bullseye-unstable] (packages: 45)
 * [bullseye] (packages: 0)
 * [buster-unstable] (packages: 56)
 * [buster] (packages: 51)
 * [focal-unstable] (packages: 56)
 * [focal] (packages: 51)

I will add the missing command to the shared library, so repositories are automatically created if a new package distribution is introduced.

[mpranj]

I tried to create it manually but it still fails. Maybe I did something wrong while creating?
Afaik the commands are still failing.

I will add the missing command to the shared library, so repositories are automatically created if a new package distribution is introduced.

Thank you!

[robaerd]

I dropped both bullseye repos and recreated them. It should now work.

I used following commands:

# bullseye
aptly repo drop bullseye
aptly repo create -architectures="amd64" -component=main -distribution=bullseye bullseye
aptly publish repo -gpg-key="A9A25CC1CC83E839" -keyring=/home/jenkins/.gnupg/pubring.kbx -batch=true --passphrase-file="/home/jenkins/.aptly/secret" bullseye bullseye

#bullseye-unstable
aptly repo drop bullseye-unstable
aptly repo create -architectures="amd64" -component=main -distribution=bullseye-unstable bullseye-unstable
aptly publish repo -gpg-key="A9A25CC1CC83E839" -keyring=/home/jenkins/.gnupg/pubring.kbx -batch=true --passphrase-file="/home/jenkins/.aptly/secret" bullseye-unstable bullseye

I can't find any docu how you created the other repos.

I will add documentation on how to do this manually to the buildserver repository. Sorry for the inconvenience.

[mpranj]

I will add documentation on how to do this manually to the buildserver repository. Sorry for the inconvenience.

Thank you! I think having the script is already great, maybe even better than any documentation that becomes outdated with time.

[markus2330]

Yes, I agree: to have these scripts in the buildserver repo is enough.