Add concurrency cancellation to all PR-triggered workflows#4318
Merged
janhoy merged 2 commits intoapache:mainfrom Apr 22, 2026
Merged
Add concurrency cancellation to all PR-triggered workflows#4318janhoy merged 2 commits intoapache:mainfrom
janhoy merged 2 commits intoapache:mainfrom
Conversation
Each new commit to a PR now automatically cancels any queued or in-progress CI runs for the same PR, preventing stale runs from blocking the queue. Adds a top-level `concurrency` block to all 9 PR-triggered workflows: - group key: workflow name + PR number (or ref as fallback) - cancel-in-progress: true
Contributor
There was a problem hiding this comment.
Pull request overview
Adds workflow-level GitHub Actions concurrency to cancel superseded runs for pull-request-triggered CI, reducing queued/stale work when new commits are pushed to the same PR.
Changes:
- Added
concurrencygroups scoped by workflow name + PR number (fallback to ref) across PR-triggered workflows. - Enabled
cancel-in-progress: trueso older queued/running executions are canceled when newer PR commits arrive.
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| .github/workflows/bin-solr-test.yml | Add concurrency/cancel-in-progress for PR script-test workflow runs. |
| .github/workflows/docker-test.yml | Add concurrency/cancel-in-progress for PR Docker build/test runs. |
| .github/workflows/gradle-extraction-check.yml | Add concurrency/cancel-in-progress for PR extraction module checks. |
| .github/workflows/gradle-precommit.yml | Add concurrency/cancel-in-progress for PR Gradle precommit checks. |
| .github/workflows/labeler.yml | Add concurrency/cancel-in-progress for PR labeler runs. |
| .github/workflows/renovate-changelog.yml | Add concurrency/cancel-in-progress for Renovate PR changelog automation. |
| .github/workflows/solrj-test.yml | Add concurrency/cancel-in-progress for PR SolrJ test runs. |
| .github/workflows/tests-via-crave.yml | Add concurrency/cancel-in-progress for PR Crave-based test runs. |
| .github/workflows/validate-changelog.yml | Add concurrency/cancel-in-progress for PR changelog validation. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
With cancel-in-progress: true, a cancelled run may not complete its Cleanup step before being forcefully terminated, leaving orphaned Crave clones. Switch the workspace path from run-scoped (GITHUB_RUN_ID_RUN_NUMBER) to PR-scoped (prs/PR_NUMBER). The "Destroy previous clone" step at the start of each new run now reliably destroys any leftover resources from a previous run for that PR — whether it ended normally, failed, or was cancelled mid-flight.
janhoy
commented
Apr 22, 2026
janhoy
added a commit
to janhoy/solr
that referenced
this pull request
Apr 22, 2026
Replace the run-scoped workspace path (GITHUB_RUN_ID_GITHUB_RUN_NUMBER) with a PR-scoped path (prs/<pr-number>) via a CRAVE_WORKSPACE env var. When cancel-in-progress cancels a run, the cleanup step may not finish, leaving a stale workspace. With a PR-scoped path, the next run's "Destroy previous clone" step will always clean up any leftover resources from a prior run for the same PR, regardless of how it ended. Backport of apache#4318.
gerlowskija
approved these changes
Apr 22, 2026
Contributor
gerlowskija
left a comment
gerlowskija
left a comment
There was a problem hiding this comment.
LGTM - nice cleanup @janhoy !
Contributor
Author
|
Proof of it working - earlier all commits would queue up, now they cancel: |
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.
I noticed that the PR check workflow queue was very long, and that a new commit to a PR would not cancel the queued checks for previous commits. This wastes resources and causes longer delay before e.g. Crave.io will test new PRs, since it is doing work noone cares about.
This PR adds a
concurrencyblock to all 9 PR-triggered GitHub Actions workflows, so that when a new commit is pushed to a PR, any previously queued or in-progress runs for that same PR are automatically cancelled.The group key is scoped per workflow + PR number, so cancellation is isolated: a new commit to PR #123 only cancels other runs of the same workflow for PR #123 — it does not affect other PRs or other workflows.
Workflows updated
All 9 PR-triggered workflows:
bin-solr-test.ymldocker-test.ymlgradle-extraction-check.ymlgradle-precommit.ymllabeler.ymlrenovate-changelog.ymlsolrj-test.ymltests-via-crave.yml← most impactful (Crave.io, 30+ min runs)validate-changelog.ymlImpact
Without this change, every commit to a PR queues a fresh run of every workflow while old runs continue to hold resources. The Crave.io queue in particular can accumulate dozens of stale runs per active branch, adding hours of unnecessary wait time for everyone. With this change, only the run for the latest commit matters — older ones are cancelled
automatically by GitHub Actions before they consume any resources.