Docker Image versioning for "next" releases

Feature Requests
,
1

The idea is:

It would be great if the released versions would follow Semantic Versioning. So you could determine if the release is stable or not.

My use case:

I’m using Renovate to automatically update the image tag for my Helm Charts.
Unfortunately the “next” images are released with a “stable” tag (without pre-release identifier at the end). So Renovate can not distinguish stable releases from unstable ones.

I think it would be beneficial to add this because:

If you would use pre-release identifiers like 1.0.0-beta or 1.0.0-rc.1 everyone could see at a glance which state the releases have.

Any resources to support this?

2

Yes, i’m in the same situation

3

So with out releases we consider Latest to be stable and Next to maybe not be as stable. We promote the versions after around a week if they are still looking good.

In this case if you are using Next we wouldn’t consider any of those to be stable even though they should be and tag to use would be Latest

4

I’m not using next or latest.
I pin the tag to a specific version. Preferably to the last stable version.

If a new version is released Renovate creates a Pull Request to update to this version.
Usually this happens only for stable versions, but in this case the pre-release versions are not distinguishable from stable versions.

So it would help, if unstable versions would have an appropriate pre-release identifier.

5

Ah I see that makes more sense, Where does Renovate get the data from is it just from Dockerhub or can it can pull from Github where releases are tagged as Latest or Pre-Release? It is not a tool I am familiar with, We are always open to tweaks though.

1 Like
6

No, currently it only supports dockerhub or custom registry as a datasource for docker-compose files.

7

@rob_otter I have had some success by setting "pinDigests": true in the renovate.json file and then setting the compose file to use the latest tag, as the renovate will then base it’s updates on eg. n8nio/n8n:latest@sha256:3ec353a93b512f6ca9c1b4203e13593dafe866b677ab6f446e6707decef52a36 and if the digest changes it will make new PR for the latest tag, but it still stands that this versioning scheme on dockerhub at least is not intuitive.

8

@ch0wm3ins yes, there is also a followTag option for that.

Unfortunately I can’t use that because the digests are different for different architectures:

image

Since I need the same version for arm64 and amd64 I need to use a tag, which automatically resolves the arch.

9

Well the image digest is not based on arch but on a “main arch-less manifest”, see this as an example manifest versioned with SHA256 · Issue #44144 · moby/moby · GitHub

So the digest renovate pins for you in a compose will resolve itself automatically to the manifest in question and then the docker engine will resolve to it’s compatible arch within the manifest sha256.

take n8n as an example:

docker buildx imagetools inspect n8nio/n8n:latest

Name:      docker.io/n8nio/n8n:latest
MediaType: application/vnd.docker.distribution.manifest.list.v2+json
Digest:    sha256:3ec353a93b512f6ca9c1b4203e13593dafe866b677ab6f446e6707decef52a36

Manifests:
  Name:      docker.io/n8nio/n8n:latest@sha256:28f177973aea9b5ee997455f3b40f387c7e63827c39646056aff9874c89b0f35
  MediaType: application/vnd.docker.distribution.manifest.v2+json
  Platform:  linux/amd64

  Name:      docker.io/n8nio/n8n:latest@sha256:d7b1368d43d0ce6ccf9ad2314c610982968357a511c276d3e09ece029c958c79
  MediaType: application/vnd.docker.distribution.manifest.v2+json
  Platform:  linux/arm64

  Name:      docker.io/n8nio/n8n:latest@sha256:0035c4264c1be6c45be135ae46e708bdf099832505972f521aeb4dbbffc8dcea
  MediaType: application/vnd.docker.distribution.manifest.v2+json
  Platform:  linux/arm/v7

The very first sha is the manifest sha which will be used when it’s a mulit-arch image.

1 Like
10

I didn’t know that, thanks for clarification.

I’ve changed it in my Helm Chars like you suggested (without pinDigests). Let’s see how Renovate handles this.

Still it would be good to use a proper tag. :slight_smile:

11

Yes it would be better with proper tags, @Jon Any plans for this?

12

It is something we are aware of but right now there are no plans. This may change in a couple of weeks though depending on where we are with our release process.