Synching Docker Base images across repositories

Exercism Building Exercism
1

Because of the recent posting of Docker image sizes, I looked into the 2 relevant erlang repositories and now reduced both images by some amount.

In that process I realized that one was using a base-image from 3 years ago, based on Ubuntu, the other one from 4 years ago, based on Alpine.

I now changed both to use the same base image.

What would be the best way to keep those in sync across both repositories, that does not involve creating an intermediary base-layer?

I also want to avoid latest like tags, and am using base images with “immutable” tags instead by choice.

2

Probably by using dependabot to automatically update to the latest version? How to keep a Dockerfile updated with Dependabot - DEV Community

3

I thought of that, though for the hexpm-BEAM images, which encode several versions in their tag, that probably doesn’t work and just gives me the “newest” tag, which might actually downgrade OTP because of push order in concurrent builds…

For Erlang the OTP version and the base distro version are encoded.
For Elixir the Elixir and OTP versions as well as the base distro version are encoded.

And especially with OTP, where we have a roughly yearly release schedule for major versions, we still receive bug fixes for year old majors might appear. Which in worst case would dependabot want me to “update” to 23.x just because that tag is newer.

Or it keeps nagging me to update to OTP 26, because yes it exists, but I consciously do not want that one, as its just a couple of month old, and I prefer to lag behind roughly a year for exercism. I do not want to push users to the newest and shiniest.

To be honest, I’d love to provide users a way to test against a selection of OTP versions, though I understand that this is probably to expensive, implementation and actual compute.

4

There might be a solution possible using exercism secrets. Let me ponder this for a bit

1 Like
5

Okay, I think I’ve come up with a system that could work. It requires us to define a GitHub actions secret that is shared with the Erlang tool repos. This secret is then used in the deploy.yml workflow to pass its value as a Docker build argument. The Dockerfiles of the Erlang tooling repos can then use this argument to build with the same version.

For an example of how this works, check out the 8th track’s test runner:

The main downsides to this approach are:

  1. It requires an action from us (the Exercism admin team) to update the version
  2. Local builds don’t have the secret value so there should be some default as we want local builds to still work

Not sure the benefits outweight the downsides here :person_shrugging: