ci: add concurrency guards to the CI, publish, and release workflows - #331
Merged
Conversation
None of the three tag- or PR-triggered workflows declared a concurrency block, so two overlapping runs could proceed in parallel — most consequentially two publishes racing on the eight-step, non-atomic Maven Central deploy. - ci.yml: cancel a superseded run only on pull requests; pushes to the integration branches keep every commit's full run. - publish.yml: funnel all Central publishes through one lane and never cancel an upload already in flight. - release.yml: one GitHub Release per tag, never cancelled mid-creation.
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.
Why
None of the three tag- or PR-triggered workflows declared a
concurrencyblock, so two overlapping runs could proceed in parallel. The consequential
case is
publish.yml: its deploy is a non-atomic sequence of eight moduleuploads to Maven Central, so two runs racing (e.g. a re-pushed tag, or a tag
push plus a
workflow_dispatchre-publish) could interleave uploads.What changed
cancel-in-progressscoped to pull requests only(
${{ github.event_name == 'pull_request' }}): rapid PR iteration collapsesto the latest commit's run, while pushes to
main/develop/2.0-devare never cancelled, so every merged commit keeps a complete recorded run.
publish-maven-central) serializes everyCentral publish through one lane;
cancel-in-progress: falseso a re-tag ordispatch never aborts an upload already in flight — it queues behind it.
release-${{ github.ref }}),cancel-in-progress: false: one GitHub Release per tag, never cancelledmid-creation; distinct tags still proceed in parallel.
Additive only — 26 lines, no job logic changed.
Verification
All three files parse as valid YAML with the
concurrencyblocks present(
yaml.safe_load), and GitHub parses the updatedci.ymlwhen it runs thisPR's own CI — a syntax error would surface as a workflow error here.
Note
publish-fonts.yml/publish-emoji.ymlalso deploy to Central (singleartifact each, so lower race risk). They could take the same guard in a
follow-up if you want full symmetry; left out here to keep this PR to the three
files the audit flagged.