Match bare-semver release tags in the multi-arch image publish

[bburda]

Pull Request

Summary

The multi-arch publish triggered on v* tags only, but release tags here are bare semver. Only the very first release, v0.1.0, used a v prefix, so this workflow has never once run from a release tag push. The trigger now matches both shapes. Neither pattern matches the bloom release/..., debian/... and upstream/... tags, which start with a letter.

To be precise about what the glob costs: this workflow was added on 2026-07-08, after 0.6.0 was released. Releases 0.2.0 through 0.6.0 have no multi-arch image because there was nothing to build them, not because of the trigger. 0.7.0 is the first release the glob could have matched, and it did not, which is why that release had to be published by a manual dispatch. :0.7.0 exists today for all three distros as a result of that dispatch; older releases have no version tag at all.

The latest tag stays with the main-branch workflow. The rule that looked like it gated latest is false for a bare semver tag, which is every release since 0.2.0, so it never fired. The tag was created anyway by the action's default flavor: latest=auto. A manual dispatch on the 0.7.0 tag moved :latest for all three distros because of that. The dead rule is gone and flavor: latest=false is what actually stops it.

---

Issue

• closes [BUG] Release tags never trigger the multi-arch image publish #665

---

Type

• Bug fix
• New feature or tests
• Breaking change
• Documentation only

---

Testing

The workflow was dispatched on the 0.7.0 tag before this change, which is how the latest behaviour was found. It produced multi-arch manifest lists for jazzy, humble and lyrical, tagged 0.7.0, 0.7 and sha-8b1969f, and also moved latest. The merge job log shows the resolved tag list as ["0.7.0","0.7","sha-8b1969f","latest"] next to type=raw,value=latest,enable=false, which is what pins the cause on latest=auto rather than on the explicit rule.

flavor: latest=false was checked against the action's source rather than assumed: it gates only the extra latest tag and does not touch how type=semver renders the version, so a bare 0.7.0 tag still yields 0.7.0 and 0.7.

The change itself was then exercised, by pushing a throwaway 0.0.1 tag at this branch. A tag push runs the workflow file the tag points at, so that run used the version in this PR.

It behaved as intended, on all three counts:

• The run started at all, from event: push on a bare semver tag. The old v* trigger would not have matched it.
• The merge job resolved its tags to ["0.0.1","0.0","sha-d120b96"], with no latest. The same job on the previous version resolved to ["0.7.0","0.7","sha-8b1969f","latest"].
• 0.0.1 and 0.0 were still produced, so flavor: latest=false gates only the extra tag and does not disturb type=semver on a tag without a v prefix.

:latest did not move: jazzy, humble and lyrical all still resolve to the digests they had before the run. The tag is gone from the repository, and the images the run published have been deleted from all three packages - the untagged per-architecture manifests as well, which a check by tag alone does not see.

---

Checklist

• Breaking changes are clearly described (and announced in docs / changelog if needed)
• Tests were added or updated if needed
• Docs were updated if behavior or public API changed