The publish job in .github/workflows/release.yml is gated only on inputs.dry-run != true. A workflow_dispatch run reaches it and retags whatever version build.zig.zon claims into latest, ${VERSION} and v${VERSION}. The guard that a tag must match the source version lives in docker-image and binary and only fires when GITHUB_REF_TYPE = tag, so a dispatch from any branch skips it. github-release is the only job gated on github.ref_type == 'tag'.
This has already overwritten a release tag. In ghcr.io/lukashes/outboxx:
0.2.0, v0.2.0, 0.2.0-4, sha-71c6f59f276b -> sha256:d19bd5516461...
Commit 71c6f59 is Use compact scratch runtime for Docker release (#67), a main commit after the release. The v0.2.0 tag is 40de3db. So ghcr.io/lukashes/outboxx:v0.2.0 does not hold the v0.2.0 release, a dispatch run replaced it.
latest, 0.3.0 and v0.3.0 currently do resolve to the v0.3.0 tag commit (47ef760), so the current state is correct. Nothing stops the next dispatch from moving them again.
Expected vs actual
- Expected:
latest, ${VERSION} and v${VERSION} move only on a tag push.
- Actual: any
workflow_dispatch run republishes them from the branch it ran on.
Ask: publish the release-facing tags only when github.ref_type == 'tag'. A dispatch run should keep building and pushing the throwaway tags (${VERSION}-${run_number}, sha-*) so manual builds stay usable.
The
publishjob in.github/workflows/release.ymlis gated only oninputs.dry-run != true. Aworkflow_dispatchrun reaches it and retags whatever versionbuild.zig.zonclaims intolatest,${VERSION}andv${VERSION}. The guard that a tag must match the source version lives indocker-imageandbinaryand only fires whenGITHUB_REF_TYPE = tag, so a dispatch from any branch skips it.github-releaseis the only job gated ongithub.ref_type == 'tag'.This has already overwritten a release tag. In
ghcr.io/lukashes/outboxx:Commit 71c6f59 is
Use compact scratch runtime for Docker release (#67), amaincommit after the release. The v0.2.0 tag is 40de3db. Soghcr.io/lukashes/outboxx:v0.2.0does not hold the v0.2.0 release, a dispatch run replaced it.latest,0.3.0andv0.3.0currently do resolve to the v0.3.0 tag commit (47ef760), so the current state is correct. Nothing stops the next dispatch from moving them again.Expected vs actual
latest,${VERSION}andv${VERSION}move only on a tag push.workflow_dispatchrun republishes them from the branch it ran on.Ask: publish the release-facing tags only when
github.ref_type == 'tag'. A dispatch run should keep building and pushing the throwaway tags (${VERSION}-${run_number},sha-*) so manual builds stay usable.