ci: stop label-gated workflows from re-triggering on every subsequent label - #17
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: CI.yml (job `call`, label 'run ci'), Documentation.yml (job `call`, label 'run documentation'), Breakage.yml (job `call`, 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
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.
Root cause
GitHub fires a separate
pull_requestevent of typelabeledfor each label added individually, and the job'sif:condition 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 several run-gating labels added one after another (e.g.run ci, thenrun documentation, thenrun breakage), any job already matched by an earlier label gets needlessly re-run again on each subsequent label-add event, since its label is still present in the set. This wastes CI runs and confuses people watching the Actions tab.Fix
For the
labeledevent specifically, checkgithub.event.label.nameagainst the job's own gating label (only that exact label re-triggers the job). For every other trigger type (synchronize/reopened/push), fall back to the existing full-label-setcontains(...)check, unchanged.Files touched
.github/workflows/CI.yml— jobcall, labelrun ci.github/workflows/Documentation.yml— jobcall, labelrun documentation.github/workflows/Breakage.yml— jobcall, labelrun breakageThese were the only workflow files matching the pattern (
pull_request: types: [labeled, ...]combined with anif:usingcontains(github.event.pull_request.labels.*.name, ...)), confirmed viagrep -rl "labeled" .github/workflows/. Other workflows (AutoAssign, CompatHelper, Coverage, Formatter, SpellCheck, TagBot, UpdateReadme) don't referencelabeledat all and were left untouched.All edited YAML files were validated with
python3 -c "import yaml; ..."and parse correctly.🤖 Generated with Claude Code