ci: stop label-gated workflows from re-triggering on every subsequent label#509
Merged
Conversation
… label
GitHub fires a separate pull_request 'labeled' event per label added, and
re-evaluates each job's `if` condition against the PR's *current* full label
set, not just the label that triggered this specific event. So adding several
run-gating labels to a PR one after another re-runs every already-matching
job on each subsequent label add, not just the newly-matched one.
Fixed by checking github.event.label.name for 'labeled' events specifically,
falling back to the existing full-label-set check for every other trigger
type. Applied to: .github/workflows/CI.yml ('call' job, label 'run ci'),
.github/workflows/Documentation.yml ('call' job, label 'run documentation'),
.github/workflows/Breakage.yml ('call' job, label 'run breakage').
Co-Authored-By: Claude Sonnet 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
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.
Root cause
GitHub fires a separate
pull_requestevent of typelabeledfor each label added individually, and the job'sifcondition is re-evaluated against the PR's current full label set every time — not just the label that triggered this specific event.So if a PR gets labels
run ci, thenrun documentation, thenrun breakageadded one after another, the CI job (already matched by the first label) gets needlessly re-run again on the second and third label-add events too, since its label is still present in the full set. This wastes CI runs and confuses people watching the Actions tab.Same root cause and fix as
control-toolbox/CTFlows.jl's recent CI.yml fix.Fix
For the
labeledevent specifically, checkgithub.event.label.nameagainst the job's own gating label; for every other trigger type (synchronize/reopened), keep the existing full-label-set check unchanged.Files changed
.github/workflows/CI.yml—calljob, labelrun ci.github/workflows/Documentation.yml—calljob, labelrun documentation.github/workflows/Breakage.yml—calljob, labelrun breakageAll other workflow files under
.github/workflows/(AddToProject, AutoAssign, CompatHelper, Coverage, Formatter, SpellCheck, TagBot, UpdateReadme) were checked viagrep -rl "labeled" .github/workflows/and do not use this pattern, so they were left untouched.Validation
All three edited YAML files parse correctly via
python3 -c "import yaml; ...".🤖 Generated with Claude Code