Consider pinning Alpine Linux minor versions in image tags

[Exagone313]

Hello,

A single Alpine Linux minor version (3.y) is used for all images built upon Alpine Linux. It means that currently, the images built upon Alpine Linux are made with the version 3.20. As the version 3.21 was recently released, the project will probably move to this new version soon (this is not the topic of the current issue).

By upgrading the Alpine Linux version, third-party images relying on Alpine Linux's package manager may break unexpectedly, as the versions of the packages installed may not be the same on each minor version of Alpine Linux.

If you compare with the images built upon Ubuntu, their tags contain the Ubuntu release code name (noble, jammy and focal at the present time).

My suggestion is to do the same for Alpine Linux version, e.g. by having image tags like 23-jdk-alpine3.20.

For backward compatibility, image tags without an Alpine Linux version specified should still be created (at least for the currently supported Eclipse Temurin versions).

Some issues to consider:

• Binaries installed in the images are built against an unspecified Alpine Linux version too, and the musl-libc version might be important
• More images to build means increased cost
• Needs to create a policy on which Alpine Linux versions are supported (see the upstream's releases page)

[reitzig]

For reference, here's a real-world Dockerfile snippet that exhibits the behaviour the OP describes:

FROM eclipse-temurin:21.0.5_11-jre-alpine@sha256:2a0bbb1db6d8db42c66ed00c43d954cf458066cc37be12b55144781da7864fdf

# Manually manage some packages that are part of the base image,
# but often lag behind updates and cause untended CVEs.
# renovate: datasource=repology depName=alpine_3_20/libcrypto3 versioning=loose
ENV LIBCRYPTO_VERSION="3.3.2-r1"
# renovate: datasource=repology depName=alpine_3_20/libssl3 versioning=loose
ENV LIBSSL_VERSION="3.3.2-r1"
RUN apk add --no-cache \
        libcrypto3="${LIBCRYPTO_VERSION}" \
        libssl3="${LIBSSL_VERSION}"

# renovate: datasource=repology depName=alpine_3_20/nodejs versioning=loose
ENV NODEJS_VERSION="20.15.1-r0"
# renovate: datasource=repology depName=alpine_3_20/npm versioning=loose
ENV NPM_VERSION="10.9.1-r0"
RUN apk add --no-cache \
        nodejs="${NODEJS_VERSION}" \
        npm="${NPM_VERSION}"

Once eclipse-temurin "silently" migrates to Alpine 3.21, we'd get a Renovate PR for the bump to 21.x.y_z-jre-alpine@sha256... with

• a red build (apk add usually breaks due to incompatible versions), and
• the Renovate comments need a manual update (cf. renovatebot/renovate#24758).

However, if the tag was 21.0.5_11-jre-alpine3.20 instead, the build would remain green as long as alpine3.20 remains, and we'd get a PR to update to -alpine3.21 (maybe with some additional config, cf. renovatebot/renovate#29501). The build of that latter one would break, of course, but it'd be a lot clearer and not block backported fixes on the alpine3.20 variant (assuming such exist).

[Exagone313]

Your use-case is similar to mine, where I needed to have Java Temurin, NodeJS and some other tools installed in a single container image for a specific CI job.

In the end, I chose to use the NodeJS Alpine Linux image as a base image, which has tags with pinned Alpine Linux and NodeJS versions, and copied the directory /opt/java/openjdk from the Java Temurin image (and set JAVA_HOME to this path).

It will break if there is an ABI incompatibility between the Alpine Linux version and the Java Temurin build when updating the versions.

[gdams]

PMC discussed this and agreed, raising changes now

[reitzig]

Tags *-alpine-3.21 and *-alpine-3.20 are now available. Thanks! 🥳