Yes, that makes much more sense. But also reduces possible gains for invested effort dramatically. We can coordinate PHP image versions easily, as there are only 2.
So, if I understand the procedure correctly, whenever we do an update / bugfix we then commit the current base image SHA to both repositories and rebuild both images? Otherwise we get out of sync. Or do we also add an Exercism base image handling the SHA for a non-changing image tag (e.g. latest), even they are not modified from the official source?
We’re only trying to sync the base layers – though syncing additional layers would be great, too. Docker images are made of layers. Typically you’d have something roughly along these lines:
Base OS
Install some packages
Set up the system
Copy the test scripts
Every time a build captures a base OS layer at a unique hash, that’s another OS layer we store. Each base OS that was previously unique gets synced to a “standard” hash, we free up that space. The goal isn’t one single base OS but to reclaim what we can by reducing the number of unique base OS layers. There are 160 Exercism repos with a Dockerfile, which could mean anywhere from 160 base images to … 50? 20?
If the two PHP images use the same base OS, that saves us some space. The test runner currently uses php:8.4.10-cli-alpine3.22 while the representer uses php:8.4-cli-alpine (aka 8.4.21-cli-alpine3.23@sha256:4f4fc56fe4ba7b7d241c371eda011b27ca4f3b25bf2a37956ee06e966777d696 as of right now). Those images are 115MB and 111MB. If both were to use, say, 8.4.21-cli-alpine3.23@sha256:4f4fc56fe4ba7b7d241c371eda011b27ca4f3b25bf2a37956ee06e966777d696 then we’d free up ~110MB.
If there’s a bug in 8.4.21-cli-alpine3.23 or if we wanted a newer version of the base OS, we’d want to update both repos to use a newer base OS layer. If there’s a bugfix in the PHP test runner itself, the base OS layer doesn’t need changing; we could update the test runner code, push a PR (which triggers a build) and get a new image which uses the same base layer but with the fix included.
Images using a base layer like Alpine, Debian or Ubuntu probably only need to be updated every 4-24 months or something, barring any security issues that may pop up. (Alpine has a major release every 6 months, Debian every year, Ubuntu LTS every two years.) Assuming all images get updates somewhat regularly, they would all be using some pool of images smaller than 160 images large Repos that haven’t been updated in a while introduce base layers with a single use which can be reclaimed by proactive bumping.
FWIW here’s the current list of base images with the tags used (the number is the total number of occurances per base/tag, not the unique tag count): gist:dc3c978dd8eca1ee28c8c96b578bd164 · GitHub
Repos that haven’t been updated in a while introduce base layers with a single use which can be reclaimed by proactive bumping.