Repository navigation
fix(ci): stop publish failing on existing immutable edge tags - #3259
Merged
Merged
Conversation
Post-merge auto-publish runs on every push to master, but component versions only change when a human bumps them. So the same immutable git tag (e.g. server-0.8.1-edge.1) is re-seen on every run after the one that first created it. check-tags treated a pre-existing tag pointing at a different commit as a wrong-target hard failure and exited 1, turning the whole workflow red and cascade-skipping publish-rust-crates and build-python-wheels. Treat tag existence as a routing signal, not a failure. In auto-publish mode (create_edge_docker_tag=true) an existing tag means the version is already released: check-tags reports it informationally instead of failing, and docker-manifests sets should_tag=false so the versioned git tag and :version manifest are skipped. The rolling :edge Docker image is still refreshed every run, and the per-component versioned release runs exactly once - on the run after a version bump, when the tag is missing. The manual publish path is unchanged: a wrong-target tag there is still a fast hard failure, because a stable release tag pointing at the wrong commit is a real error rather than the expected steady state.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #3259 +/- ##
============================================
- Coverage 73.87% 73.83% -0.05%
Complexity 943 943
============================================
Files 1193 1193
Lines 108970 108970
Branches 85988 86005 +17
============================================
- Hits 80506 80462 -44
- Misses 25729 25749 +20
- Partials 2735 2759 +24
🚀 New features to boost your workflow:
|
mmodzelewski
approved these changes
May 14, 2026
spetz
approved these changes
May 14, 2026
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
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.
Post-merge auto-publish runs on every push to master, but
component versions only change when a human bumps them. So the
same immutable git tag (e.g. server-0.8.1-edge.1) is re-seen on
every run after the one that first created it. check-tags
treated a pre-existing tag pointing at a different commit as a
wrong-target hard failure and exited 1, turning the whole
workflow red and cascade-skipping publish-rust-crates and
build-python-wheels.
Treat tag existence as a routing signal, not a failure. In
auto-publish mode (create_edge_docker_tag=true) an existing tag
means the version is already released: check-tags reports it
informationally instead of failing, and docker-manifests sets
should_tag=false so the versioned git tag and :version manifest
are skipped. The rolling :edge Docker image is still refreshed
every run, and the per-component versioned release runs exactly
once - on the run after a version bump, when the tag is missing.
The manual publish path is unchanged: a wrong-target tag there
is still a fast hard failure, because a stable release tag
pointing at the wrong commit is a real error rather than the
expected steady state.