Skip to content

docs(README): clarify how tags: set version - #562

Closed
br3ndonland wants to merge 1 commit into
docker:masterfrom
br3ndonland:tags-priority
Closed

docs(README): clarify how tags: set version#562
br3ndonland wants to merge 1 commit into
docker:masterfrom
br3ndonland:tags-priority

Conversation

@br3ndonland

@br3ndonland br3ndonland commented Nov 14, 2025

Copy link
Copy Markdown

Description

Closes #561

The README says,

The first tag in the list (higher priority) will be used as the image version for generated OCI label and version output.

That doesn't seem to be correct.

Example run here.

Workflow file had type=sha listed first:

- name: Set up metadata
  id: meta
  uses: docker/metadata-action@c1e51972afc2121e065aed6d45c65596fe445f3f # v5.8.0
  with:
    images: ghcr.io/${{ github.repository }}
    flavor: |
      latest=${{ github.ref_type == 'tag' || github.ref_name == 'main' }}
    tags: |
      type=sha
      type=ref,event=branch

But then the action output was org.opencontainers.image.version=main.

Screenshot of GitHub Actions workflow run logs showing that the version label was not assigned based on list order

Changes

This PR will update the wording in the README to clarify that version is determined by the highest-priority tag in the tags: input list, regardless of the order of the items in the input.

Signed-off-by: Brendon Smith <bws@bws.bio>
@polarathene

Copy link
Copy Markdown

The first tag in the list (higher priority)

If you read the priority attribute docs a little bit more you might see where your misunderstanding was?

metadata-action/README.md

Lines 794 to 810 in 318604b

### `priority` attribute
`priority=<int>` attribute is used to sort tags in the final list. The higher
the value, the higher the priority. The first tag in the list (higher priority)
will be used as the image version for generated OCI label and [`version` output](#outputs).
Each tags `type` attribute has a default priority:
| Attribute | Default priority |
|------------|------------------|
| `schedule` | `1000` |
| `semver` | `900` |
| `pep440` | `900` |
| `match` | `800` |
| `edge` | `700` |
| `ref` | `600` |
| `raw` | `200` |
| `sha` | `100` |

Just like the first sentence clarifies, priority is used to sort the list of tags. Each tag type has a default priority value assigned, where ref (600) is higher than sha (100), that is why you observed the ref tag coming first.

When the docs refer to the first tag in the list to be selected, it is not referring to the unsorted tags input, but after sorted by priority. When you have multiple tags of the same priority how do you select which one to choose? The documented behaviour is the first one in that list is chosen (which implies tags preserves order of each tag of the equivalent priority).

    tags: |
      type=sha
      type=raw,value=hello
      type=raw,value=bello

The hello tag has a priority of 200, and it's declared before bello which is also 200 priority. The sha tag is lower priority, so hello is selected.

Your PR here would be removing this useful information.

@crazy-max crazy-max closed this Nov 28, 2025
br3ndonland added a commit to br3ndonland/dovi_tool that referenced this pull request Jul 3, 2026
The GitHub Actions actions for Docker, such as docker/build-push-action,
have some drawbacks:

- The Docker actions may be confusing to use
  (docker/build-push-action#80, docker/metadata-action#561,
  docker/metadata-action#562).
- The Docker actions may silently allow antipatterns. For example, when
  specifying annotation levels, Docker
  [documents](https://docs.docker.com/build/metadata/annotations/#specify-annotation-level)
  that "the build must produce the component that you specify, or else
  the build will fail." This means that building a single-platform image
  with `DOCKER_METADATA_ANNOTATIONS_LEVELS="index,manifest"` should fail
  (and does, with the Docker CLI), because single-platform builds can't
  apply index annotations. However, with the Docker actions, this error
  is silently allowed (for an example of an incorrect workflow that
  succeeds, see
  [br3ndonland/infrastructure-live](https://github.com/br3ndonland/infrastructure-live/blob/b57f978b781fb3a31d73854d9e4090f6f505c2f4/.github/workflows/ci.yml#L114-L122)).
- Including Docker actions in GitHub Actions workflows necessitates
  version updates. That means more Dependabot or Renovate bot PRs that
  have to get reviewed and merged, or more manual updates if bots aren't
  used.
- The maintainers aren't always attentive to community contributions
  (docker/metadata-action#587). Why wait months or years for maintainers
  to consider adding something to the actions when you can just do it
  directly with the Docker CLI right now?
- Docker actions make it more difficult to align CI image builds with
  local development builds. Local development builds typically use CLI
  commands, but the actions are opaque TypeScript libraries.

It would be simpler to replace the actions with CLI commands instead.

The actions can be easily replaced:

1. docker/setup-buildx-action is unnecessary because Buildx is included
   on GitHub Actions runners by default. Its "builders" can be set up
   with `docker buildx create` commands.
2. docker/login-action can be replaced with `docker login` commands.
3. docker/metadata-action can be replaced by specifying metadata inputs
   as environment variables.
4. docker/build-push-action can be replaced with `docker buildx build`
   commands. As a starting point, the commands can be based on outputs
   of previous docker/build-push-action GitHub Actions workflow jobs.
5. crazy-max/ghaction-github-runtime (for setting up the "GHA" GitHub
   Actions cache) can be replaced with a simple Node.js action that
   exports environment variables for later shell steps.

This commit will implement a replacement for the above five actions with
a script and local Node.js action. The README will document how to use
the replacement script and action.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

priority does not respect tags: input order

3 participants