Store CI images in a different docker org than precice

[fsimonis]

Currently, preCICE stores CI images and release images in the same org precice. This makes discoverability problematic as there is a lot of visual clutter. Also, CI images are used more frequently, which makes the situation even worse when sorting.

Proposed solution by @BenjaminRodenberg here is to store CI and release images in separate orgs.
The precice org should be the one for release images.

The org for CI images could be:

• A new dockerhub org (may be violation of TnS)
• The github container registry of precice, which we already use for systemtests.

@MakisH Could we run into a bandwidth issue here?

[MakisH]

Important to clarify before we continue: For the system tests, we don't need anymore that every repository publishes Docker images. We build those on-demand in a specific system and handle caching via multi-stage Docker builds.

So, we are talking here mainly for the ci-images (what else?).

These are images don't need to be published and Docker Hub is kind of the default, world-accessible hub for images. So, by putting CI images there, we essentially tell the world "use these", or we make it more difficult to find the right ones. Some organizations fix that by guiding users via the organization README on Docker Hub.

With that said, I think it is a good idea to either edit the Docker Hub repository description, or move any such CI images into the GitHub container registry (did not exist when we first needed it).

@MakisH Could we run into a bandwidth issue here?

According to the GitHub documentation, the current limits in the free plan are 1GB data transfer per month and 500MB storage. This is a separate limit than, e.g., Git LFS.

However, our images seem to be much more than 500MB. I guess I either read the wrong GitHub documentation page, or the GHCR is not really intended for Docker images.

If I understand correctly, the Docker Hub rate limit is more relaxed.