Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

discussion: should we move OCI images to github container registry #71

Closed
flavorjones opened this issue Jun 27, 2022 · 3 comments
Closed

Comments

@flavorjones
Copy link
Collaborator

Currently, the official rake-compiler-dock OCI images are hosted on Dockerhub at https://hub.docker.com/u/larskanis which is @larskanis's personal dockerhub account.

This has worked well so far, but recently I wanted to cut a release of rake-compiler-dock and, although I have privileges to commit to the github repo and push a gem to rubygems.org, I do not have privileges to push to https://hub.docker.com/u/larskanis.

I wanted to suggest the possibility of moving to Github's container registry (https://ghcr.io) which I've been using to manage test container images for about a year and I've found it to be reliable and easy to use.

The primary benefit of GHCR for us is that the permission to push images is managed by the github team/repo role, which means non-Lars maintainers can cut a new release. A secondary benefit might be the ease of publishing from a Github Action job, which would enable us to ship "nightly" container images if that's something we decide would be useful/helpful.

I'm happy to do the work to make all this happen, but first wanted to see if there were objections.

@larskanis
Copy link
Member

I only have one objection: So far I tried to minimize download sizes between patch releases. This is usually possible, since only minor things have changed and we have a lot of docker image layers, where only the very latest layers usually need an update.

So I use one an the same docker installation and the base image versions from my cache and then the docker push is pretty fast, printing "Layer already exists" in most cases and uploading just only a few megabytes.

I guess that minimizing download sizes between patch releases is a feature, that is hard to implement with automatic builds. Isn't it?

@flavorjones
Copy link
Collaborator Author

@larskanis If we embrace automated builds, I think there are a few tricks we can try to cache and re-use image layers, and I'd be happy to make that a requirement for any automated build system.

But I'm not proposing automated builds here! I'm only proposing that we push images to ghcr.io instead of dockerhub so that they're explicitly coupled to the git repo and we can use our committer privileges to do so. We can document the manual process for pushing images so that unchanged layers are re-used.

@flavorjones
Copy link
Collaborator Author

Done in #84

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants