search

rake-compiler / rake-compiler-dock

Easy to use and reliable cross compiler environment for building Windows, Linux, Mac and JRuby binary gems.
MIT License
77 stars 30 forks source link

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

Closed flavorjones closed 1 year ago

flavorjones commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 1 year ago

Done in #84