gap-system
Investigate using GitHub Container Registry instead of / in addition to Docker Hub
Docker Hub on November 2 started to introduce rate limiting for usage of Docker images hosted there, see https://www.docker.com/increase-rate-limits . To their credit, they gave ample warning, announcing this months ago, and the limit is introduced gradually; still, we should plan ahead for alternatives.
One of those is GitHub Container Registry, introduced here: https://github.blog/2020-09-01-introducing-github-container-registry/. Docs here: https://docs.github.com/en/free-pro-team@latest/packages/getting-started-with-github-container-registry/about-github-container-registry.
Let's figure out a way to use that for our Docker images; besides the "obvious" manual way, I am hoping for something automatic, where a push to the GAP git repository triggers creation of a new Docker image (if that's not too unreasonable). I know that DockerHub offers such a feature. However, as I understand it, that requires a Dockerfile in https://github.com/gap-system/gap ? And I am not sure if the GitHub container registry supports it? Perhaps one needs to use GitHub Actions there? Well, as I said, somebody ought to figure this out and make this work. I'd be happy to assist (it may need giving extra access permissions etc.).
BTW, I am not actually sure how https://hub.docker.com/repository/docker/gapsystem/gap-docker-master/ gets updated regularly, yet it tracks https://github.com/gap-system/gap-docker-master which hasn't been updated since July. I could not figure out exactly what makes this tick; but I think this is triggered by a job running on the Jenkins server in St Andrews. Perhaps @alex-konovalov can confirm this? In any case, I'd personally prefer if this was done via GitHub Actions or some other public means, so that more people can edit it if necessary. And yeah, this is one more thing we really, really should document somewhere...
OK it seems that under https://github.com/gap-system/gap/actions/new one can click on "More continuous integration workflows" and then scroll a lot, then there are two premade workflows "Publish Docker Container" and "Docker image" which we likely can adapt; we should just move the Dockerfile to the GAP repository for that. Which makes sense, I guess?
Sorry, I've missed this ping. So, a Docker container build may be triggered by a commit to a repository, or manually using the DockerHub web interface, or automatically. For the latter option, there are two nightly Jenkins builds, accessible only from St Andrews:
- https://gap-ci.cs.st-andrews.ac.uk/job/gap-docker-master-trigger/
- https://gap-ci.cs.st-andrews.ac.uk/job/gap-docker-stable-4.11-trigger/ and you can see at https://hub.docker.com/u/gapsystem what are the latest times these (and some older) containers were built.
The script which those jobs run is one line, and it can be run from anywhere (I sometimes was using it to initiate a build from my machine, when Jenkins queue was too long and I wanted a test):
curl -H "Content-Type: application/json" --data '{"build": true}' -X POST https://hub.docker.com/api/build/v1/source/token/call/
where the token is something you get via GitHub API - I am not sure that it should be seen on a public infrastructure, but perhaps there are proper ways of doing that under "Publish Docker Container" and "Docker image" mentioned above.
It is awesome idea and makes the ecosystem homogenous. The only disadvantage we have is that you have to be authenticated:
https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry
We could use both for redundancy.
Yep, I believe we had something working in a similar direction in gap-system/gap-container that was implemented in this PR. I think it should already contain the GAP system?
@ZachNewbery Yup.
I would stick to having both registries for redundancy. I am sure sure we should consolidate all of the docker-* repositories we have.
@limakzi Agreed, though I would also suggest we canonicalize the GHCR.io docker images as the standard ones for new users, just to pre-emptively move as many users a possible to using them over the Dockerhub images (further avoiding reaching the rate limits). Then we could discuss deprecating them in a while once usage has dropped?
@ZachNewbery I am sure we cannot use GHCR.io registry as main one. As far as I know, there is no possibility to download ghcr.io hosted image without Github token. I do not want the end user need to login to GHCR to get the GAP image.
That would be awful.
Said that, I would always suggest the end user to download GAP image from Dockerhub and give the alternative to download these from GHCR.io. We will be using GHCR.io images for internal infrastructure jobs.
And of course, there exists 1-to-1 mapping between image in Dockerhub and image in GHCR.io.
First sketch available here: https://github.com/limakzi/gap-docker/actions/runs/10723164174/job/29735823669
@limakzi Agreed, it would be terrible if it is required to use the Github token for all pulls. There does seem to be some functionality in controlling visibility here, but I'll need to investigate more if that mirrors the semantics of public Dockerhub images (entailing no more need for token auth). Seems that public images allow anonymous pulling, but then again not sure if that still requires an initial login call.
@ZachNewbery Aha. It works. :) If you set package as public - it is publicly available and there is no need to use token
https://github.com/limakzi/gap-docker/pkgs/container/gap-docker
>> feature/add-gap-version-matrix λ docker pull ghcr.io/limakzi/gap-docker:main
main: Pulling from limakzi/gap-docker
f6fe61417ce4: Pull complete
7e67b02a5905: Pull complete
6471b3e18cdc: Pull complete
7b8b2025ee32: Pull complete
5e7ec38a06f9: Pull complete
Digest: sha256:97734da20e3289c520a1d35e9a943f0c521d5fc73e9581d18021ddd6e9d12454
Status: Downloaded newer image for ghcr.io/limakzi/gap-docker:main
But, still, I would keep Dockerhub as mirror.
Amazing, glad to hear it! Yes agreed, we should keep Dockerhub as a mirror at current and try to slowly migrate users across.