Also publish to GitHub container registry

[timja]

Any thoughts?

I've done an experiment here:
https://github.com/timja/jenkins-ci.org-docker/pkgs/container/jenkins

see https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry

Steps taken:

• Logged in with a github pat (see above doc)
• Pushed image
• Went to packages on my profile and linked it to this repo (on my fork)
• Updated the package setting to be public instead of private (one off change per image, not per tag)

The main benefit I see is there's pull metrics per tag.
It amazes me that docker hub does not provide this =/. I want to know if anyone actually uses e.g. centos or windows tags.

cc @dduportal @MarkEWaite @slide @olblak

[olblak]

I wouldn't leave dockerhub because well it's still the default place to go but I don't see any objection to push images to ghcr as well. I am using it for updatecli from here and it's working great

[slide]

I also think we shouldn't leave dockerhub, people look there first for images. I think ALSO publishing to ghcr would be fine.

[MarkEWaite]

I think publishing to GitHub container registry is a great idea in addition to Dockerhub.

[dduportal]

+1 on this: with the recent addition of docker buildx bake, it should be easy on the pipeline side.

@timja since I recently got warned by GitHub that I'm consuming too much space, could you check the limitations (size/API rate) on the GitHub that we would have if we do so?

[timja]

free for public packages, and doesn't appear to be any limits:
https://docs.github.com/en/billing/managing-billing-for-github-packages/about-billing-for-github-packages#about-billing-for-github-packages

[olblak]

I am not aware of any limits and I would definitely be in favor to publish on ghrc.io

[AdmiralNemo]

Please consider this. It's very easy to run afoul of the Docker Hub rate limiting nowadays. This happened to me recently when one of my Kubernetes nodes failed and a whole bunch of pods had to be moved to different nodes. The simultaneous pulling of several images tripped the rate limit, preventing a bunch of processes from starting.

[dduportal]

Please consider this. It's very easy to run afoul of the Docker Hub rate limiting nowadays. This happened to me recently when one of my Kubernetes nodes failed and a whole bunch of pods had to be moved to different nodes. The simultaneous pulling of several images tripped the rate limit, preventing a bunch of processes from starting.

The Jenkins images are not subject to the API rate limit on the DockerHub, as part of the OSS Sponsoring program by Docker.

If you did have rate limit with any jenkins/* images, it could have been during a short period of time as Docker and us did messed up the setup during ~24h but it is now fixed: jenkins-infra/helpdesk#4720.

[lemeurherve]

From #1228 (comment) (emphasis on the relevant part for this issue):

Details

FTR, I've started working on this as I'd like to be able to validate publication from changes like #2189 before actual Weekly or LTS releases.

For #1140, I've got required changes in this repository ready and tested on my own registries, I now need to work on adapting https://github.com/jenkins-infra/pipeline-library/blob/5c992ff2fe2676f0d206dda285bb76dc71c0b9b5/vars/infra.groovy#L32-L69 and to create a classic token (with https://github.com/settings/tokens/new?scopes=write:packages cf https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry#authenticating-with-a-personal-access-token-classic) then store it on trusted.ci.jenkins.io controller.

I recon there are other target registries discussed in jenkins-infra/helpdesk#4731, but I figured I could get the ball moving by starting implementing #1140, which will unlock further development.

EDIT: put in pause until at least after LTS 2.541.1 publication cf #1228 (comment)