Walkthrough

Adds concurrency configuration to four GitHub Actions workflow files (examples, gem-tests, integration-tests, and playwright), enabling automatic cancellation of in-progress runs when new commits are pushed to the same branch or pull request, reducing runner pool contention.

Changes

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐰 Four workflows now heed the call,
No more runners wasting all,
When new commits make their way,
Old runs fade and workflows play,
Concurrency saves the day! ✨

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.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Greptile Summary

Adds a workflow-level concurrency block to examples.yml, gem-tests.yml, integration-tests.yml, and playwright.yml using the same pattern: PR events group by PR number with cancel-in-progress: true, while push-to-main and workflow_dispatch events group by commit SHA with cancel-in-progress: false, ensuring each main-branch commit keeps its own isolated run.

Confidence Score: 5/5

Safe to merge — workflow-only change with no impact on production code; concurrency logic is correct and consistent across all four files.

All findings are P2 or below. The concurrency pattern correctly scopes PR runs by PR number (with cancellation) and main-branch runs by SHA (without cancellation). The previously raised playwright.yml concern is fully addressed in the current implementation.

No files require special attention.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Workflow triggered] --> B{Event type?}
    B -->|pull_request| C["group = '{workflow}-pr-{pr_number}'"]
    B -->|push to main / workflow_dispatch| D["group = '{workflow}-{sha}'"]
    C --> E["cancel-in-progress: true"]
    D --> F["cancel-in-progress: false"]
    E --> G[New commit cancels prior PR run]
    F --> H[Each commit gets isolated run, no cancellation]

_{Reviews (2): Last reviewed commit: "fix: use PR-number concurrency groups an..." | Re-trigger Greptile}

Review: Add concurrency groups to CI workflows

Overall this is a solid, low-risk improvement using the standard GitHub pattern. Adding concurrency cancellation to the three workflows that also run on pull_request (gem-tests.yml, integration-tests.yml, examples.yml) is a clear win — PR branches get stale-run cancellation, and even if main push runs cancel each other, CI was already verified at the PR level.

One concern worth addressing — playwright.yml:

Unlike the other three workflows, playwright.yml only triggers on push to main (not on pull_request). This makes it the sole per-commit verification for Playwright tests. With the current cancel-in-progress: true and a shared concurrency key based on github.ref, two merges to main in quick succession will cause the first commit's Playwright run to be cancelled — leaving it permanently unverified.

The fix is to use github.sha as the group key so each commit on main gets its own isolated run:

concurrency:
  group: ${{ github.workflow }}-${{ github.sha }}
  cancel-in-progress: true  # still cancels duplicate workflow_dispatch re-runs of the same SHA

See the inline comment for the specific change. The other three files look good as-is.

Review feedback addressed in b33ddc6

All review comments have been addressed with a single commit that updates the concurrency configuration in all four workflows.

Changes made

1. Main branch runs are no longer cancelled (raised by @cursor[bot], @greptile-apps[bot], @claude[bot])

• Changed cancel-in-progress: true to cancel-in-progress: ${{ github.event_name == 'pull_request' }}
• Main branch pushes now always run to completion, matching the pattern already used in benchmark.yml
• Especially important for playwright.yml which only runs on main pushes

2. Fork-safe concurrency group keys (raised by @chatgpt-codex-connector[bot])

• Replaced github.head_ref || github.ref with github.event.pull_request.number (PR number, unique per PR) with github.sha fallback for non-PR events
• Two fork PRs with the same branch name (e.g. patch-1) no longer cancel each other's CI runs

Concurrency behavior after this change

To use Codex here, create an environment for this repo.

Review

The approach is correct and safe. A few things worth noting:

The concurrency expression works as intended

group: ${{ github.event.pull_request.number && format('{0}-pr-{1}', github.workflow, github.event.pull_request.number) || format('{0}-{1}', github.workflow, github.sha) }}
cancel-in-progress: ${{ github.event_name == 'pull_request' }}

• On PR events: groups by {workflow}-pr-{number} → new commits cancel stale runs for the same PR ✓
• On push to main or workflow_dispatch: groups by {workflow}-{sha} (unique per commit) + cancel-in-progress: false → runs on main are never cancelled ✓
• No cross-workflow collisions since each workflow has a unique name in the group key ✓

playwright.yml concurrency block is a no-op

playwright.yml only triggers on push: branches: [main] and workflow_dispatch, never on pull_request. This means the concurrency block never groups or cancels anything there. See inline comment. Not a blocker, but worth clarifying intent.

Other PR-triggering workflows were skipped

lint-js-and-ruby.yml and package-js-tests.yml both run on PRs but weren't covered. These are presumably shorter-running than the four targeted here, but they'd benefit from the same treatment if there's queue contention on those too.

PR description vs. implementation

The description says "Uses the standard GitHub pattern: group: ${{ github.workflow }}-${{ github.head_ref || github.ref }}" but the actual implementation uses PR number + SHA fallback — which is a better approach (avoids ambiguity with branch names containing slashes, more explicit about main-branch protection). Minor nit: the description could be updated to match the actual pattern used.