Use full semver for OCI annotation #14177

New Issue

GiteaMirror · 2025-11-02T11:05:24-06:00

GiteaMirror commented

2025-11-02 11:05:24 -06:00

Originally created by @arifer612 on GitHub (Feb 23, 2025).

Feature Description

The Issue

The OCI annotation org.opencontainers.image.version is always 1, the major version, in all the tagged releases since v1.23.1. This is opposed to it being the full semver, e.g., 1.23.4 for the latest release, which is what one would expect.

This happens because the docker/metadata-action action in .github/workflows/release-tag-version.yml is told to generate tags in the following order:

major version first,
major + minor version next, and
the full semver last.

According to the documentation for the action, such an order (without any priorities set), would mean that first tag generated, i.e., the major version, would be used as the value of the OCI annotation. This is indeed what we observe.

This only affects the version-tagged releases; the nightly releases are not tagged with any version number, so this issue does not exist; the rc-tagged releases only generate a single tag, so the OCI annotation is always correct.

The Feature Request/Suggestion and a Proposed Solution

I would like to suggest that the annotation reflect the full semver, instead of just the major version.

This is a very simple fix to .github/workflows/release-tag-version.yml. All that needs to be done is to either

change the order of tags that the docker/metadata-action action generate, or
increase the priority of the tag that corresponds to the full semver.

If my suggestion and proposed solution is agreeable, I can make the changes and do up the PR right away.

Screenshots

No response

Originally created by @arifer612 on GitHub (Feb 23, 2025). ### Feature Description ### The Issue The OCI annotation `org.opencontainers.image.version` is always `1`, the major version, in all the tagged releases since v1.23.1. This is opposed to it being the full semver, e.g., `1.23.4` for the latest release, which is what one would expect. This happens because the `docker/metadata-action` action in `.github/workflows/release-tag-version.yml` is told to generate tags in the following order: 1. major version first, 2. major + minor version next, and 3. the full semver last. According to the [documentation for the action](https://github.com/docker/metadata-action#priority-attribute), such an order (without any priorities set), would mean that first tag generated, i.e., the major version, would be used as the value of the OCI annotation. This is indeed what we observe. This only affects the version-tagged releases; the nightly releases are not tagged with any version number, so this issue does not exist; the rc-tagged releases only generate a single tag, so the OCI annotation is always correct. ### The Feature Request/Suggestion and a Proposed Solution I would like to suggest that the annotation reflect the full semver, instead of just the major version. This is a very simple fix to `.github/workflows/release-tag-version.yml`. All that needs to be done is to either 1. change the order of tags that the `docker/metadata-action` action generate, or 2. increase the priority of the tag that corresponds to the full semver. If my suggestion and proposed solution is agreeable, I can make the changes and do up the PR right away. ### Screenshots _No response_

GiteaMirror added the type/proposal topic/build labels 2025-11-02 11:05:24 -06:00

GiteaMirror closed this issue

2025-11-02 11:05:24 -06:00

GiteaMirror commented

2025-11-02 11:05:25 -06:00

@techknowlogick commented on GitHub (Feb 23, 2025):

Reordering them seems reasonable, and if it would be a benefit if the labelling of the images then we'd love to have a PR to do this. Thanks for bringing this up:)

@techknowlogick commented on GitHub (Feb 23, 2025): Reordering them seems reasonable, and if it would be a benefit if the labelling of the images then we'd love to have a PR to do this. Thanks for bringing this up:)

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#14177