Repository navigation
build(ci): detect changes in-job and cancel superseded PR runs - #2010
Merged
Merged
Conversation
The change detection ran as a job of its own that every build job needed, so each build queued twice on the shared ASF runner pool: once for the two-second detection job, then again for its own runner. Over the last ~40 runs that first wait averaged 37 minutes (max 97) before a build job could even enter the queue. Detection now runs as a step at the start of each job, from a local composite action, and gates the remaining steps. Each job queues once. Every workflow also gets a concurrency group: a new push to a pull request cancels the superseded run, while pushes get a group per run so no branch build is dropped. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
lukaszlenart
marked this pull request as ready for review
October 14, 2026 08:53
lukaszlenart
enabled auto-merge
October 14, 2026 08:53
|
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
GitHub Actions jobs on this repo spend far longer queued than running. Over the last ~40 completed runs:
changes(2 s job)The queue is the shared ASF runner pool, which we cannot change. But we were doubling our own wait: every build job
needs: changes, a separate job, so each build queued once for the two-second detection job and then again for its own runner.Smaller runners such as
ubuntu-slimdo not help: GitHub documents them as sharing the concurrency model of the standard runners, and the table shows a 2 s job queues as long as a 7 min one.What changes
.github/workflows/changes.ymlbecomes the local composite action.github/actions/detect-changes. The path logic and skip pattern are unchanged. Each job (Maven matrix, CodeQL, OWASP, Sonar) now runs checkout → detect → the real steps gated onsteps.changes.outputs.code == 'true'.if:and gate their steps instead, so a docs-only change reports success rather than skipped.maven.ymlalready did this.pull-requests: read, which the removedchangesjob already had.concurrencygroup keyed by PR number withcancel-in-progress: true. Pushes are keyed byrun_id, so GitHub's rule that a newer pending run replaces an older one cannot drop a stacked build onmain.Trade-off
A docs-only change now briefly takes a runner in each of the four jobs (detection, then every step skipped), instead of one
changesrunner per workflow. The runner cost is about the same, and code changes lose the whole first wait.Verification
actionlint1.7.12 is clean apart from two pre-existing shellcheck infos in the unchanged "SonarCloud Scan -- SKIPPED" step.changes / Detect changes …job.🤖 Generated with Claude Code