fix(build): tag images by version and major.minor instead of latest - #632
Open
stevapple wants to merge 1 commit into
Open
fix(build): tag images by version and major.minor instead of latest#632stevapple wants to merge 1 commit into
stevapple wants to merge 1 commit into
Conversation
Every v* tag pushed :latest, so a patch released on an older line or
a pre-release tag would move it backwards. Rather than making :latest
smarter, drop it: before 1.0 every minor is allowed to break
compatibility, so a floating latest silently carries consumers across
compatibility boundaries. A moving {{major}}.{{minor}} tag lands
exactly on that boundary in 0.x and serves the same purpose.
Tags now come from docker/metadata-action with {{version}} and
{{major}}.{{minor}}. flavor: latest=false is required because the
action would otherwise add latest on its own, its default being
latest=auto. Nothing has to consult the rest of the tag history: a
patch published on an older line moves only its own line, and
pre-releases only ever extend {{version}}, never a moving tag.
The labels output is wired through as well, since
org.opencontainers.image.source is what links the GHCR package back
to this repository.
Note that {{version}} strips the v prefix, so images are tagged
:0.3.0 rather than :v0.3.0. No release has been cut since modelpack#631, so
nothing already published is affected.
Signed-off-by: YR Chen <stevapple@icloud.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #631, addressing @chlins's review comment about
:latestbeing overwritten by everyv*tag.Rather than making
:latestsmarter, this drops it. Before 1.0 a floatinglatestis actively hazardous: every 0.x minor is allowed to break compatibility, so anything that pullsmodctl:latestsilently changes behaviour from one release to the next. What it is really useful for — "track this line without pinning every patch" — is served better by a moving{{major}}.{{minor}}tag, which in 0.x maps exactly onto the compatibility boundary.Changes
docker/metadata-actionwith two semver patterns:{{version}}for the immutable tag, and{{major}}.{{minor}}as the moving tag for a release line.flavor: latest=falsekeeps the action from addinglateston its own (its default islatest=auto).labels: ${{ steps.meta.outputs.labels }}comes along with the action, andorg.opencontainers.image.sourceis what links the GHCR package back to this repository.Nothing needs to consult the rest of the tag history:
{{major}}.{{minor}}only ever moves within its own line, so a patch published on an older line updates that line alone and leaves newer ones untouched. Pre-releases never move a shared tag at all — the action only extends{{version}}for them.Resulting tags
v0.3.00.3.0,0.3v0.2.3(patch on an older line)0.2.3,0.2v1.0.0-rc.1(pre-release)1.0.0-rc.1v0.2.1-cnai(variant tag)0.2.1-cnaiBehavioral change worth confirming
{{version}}strips thevprefix, so images becomeghcr.io/modelpack/modctl:0.3.0where the merged workflow would have pushed:v0.3.0. No release has been cut since #631 merged, so nothing already published is affected either way. This is what{{major}}.{{minor}}produces anyway and what most images conventionally use.Testing
The four rows in the table above are actual output from
docker/metadata-actionv6.2.0 run against these inputs, and both pre-release forms this repository uses (-rc.Nand the-cnaivariant) correctly produce only their exact version.