[kixelated]

Problem

A newer push to a PR leaves the older pr run holding runners until it finishes, and the org shares a 60-job hosted-runner cap.

Approach

Give pr.yml a top-level concurrency group per PR with cancel-in-progress: true, so a new push cancels both jobs of the superseded run.

Impact

No public API or wire impact. Only runs of the same PR cancel each other.

Validation

• actionlint on pr.yml: clean. zizmor: no new findings.
• just check: passes.

Models

Size: XS
Implementer: Claude Code, claude-opus-5-5, high effort

(Written by Claude Opus 5.5 with high)

🤖 Generated with Claude Code

Review

Rewritten by quest review after each round.

• Reviewer: Codex, gpt-6.1-sol, low effort
• Session: 01a1d21b-2ee3-75b3-adaf-fc0320e307cb, round 1
• Head: 6bff518
• Base: origin/main at 9d9e9d7
• Score: 10/10, The change correctly scopes concurrency to each PR and cancels superseded runs without affecting other PRs; no actionable issues were found.
• Findings: none

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

The PR workflow now groups runs by pull request number, or by Git ref when a pull request number is unavailable. A new run cancels an in-progress run in the same group.

Merge Risk: Minimal · up to 6bff5

The change cancels superseded runs of the same pull request to free runner capacity. No actionable merge risk was found.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title "ci: cancel superseded pull request runs" matches the main change. The raw summary and objectives both say pr.yml gets a per-PR concurrency group with cancel-in-progress, so a newer run canc…
Description check		The description states the problem (superseded PR runs hold runners under a shared 60-job cap), the approach (a top-level per-PR concurrency group with cancel-in-progress in pr.yml), the impact (only …
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Title check

Explanation

The title "ci: cancel superseded pull request runs" matches the main change. The raw summary and objectives both say pr.yml gets a per-PR concurrency group with cancel-in-progress, so a newer run cancels the older one. The title is specific and short, and it uses the conventional commit prefix.

Full details: Description check

Explanation

The description states the problem (superseded PR runs hold runners under a shared 60-job cap), the approach (a top-level per-PR concurrency group with cancel-in-progress in pr.yml), the impact (only runs of the same PR cancel each other), and validation steps. It is directly related to the changeset.

Finishing Touches

Simplify code

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

Recent review info

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 78160a89-5d89-4218-b788-5f5a6d83f787

Commits

Reviewing files that changed from the base of the PR and between 9d9e9d7 and 6bff518.

Files selected for processing: 1

• .github/workflows/pr.yml

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

[pullfrog]

✅ No new issues found.

Reviewed changes

Reviewed the single workflow change in .github/workflows/pr.yml.

• PR-scoped concurrency group: adds a top-level concurrency block with group: pr-${{ github.event.pull_request.number || github.ref }} and cancel-in-progress: true, so a new push cancels the superseded run's check and toolchain jobs. The workflow only triggers on pull_request, so each PR gets its own group and other PRs are unaffected.

  ^{｜ View workflow run ｜ Using claude-sonnet-5-5 ｜ 𝕏}