fix: add concurrency group to codegraph-impact workflow

[carlos-alm]

Summary

• The codegraph-impact.yml workflow was the only CI workflow missing a concurrency group
• Without it, every push to every open PR queued a new run without cancelling stale ones
• With many PRs active simultaneously, this starved the GitHub Actions runner pool and left jobs queued for over an hour
• Adds concurrency with cancel-in-progress: true, scoped per PR number — matching the pattern already used by ci.yml, embedding-regression.yml, and publish.yml

Test plan

• Verified all other workflows already have concurrency groups
• Push multiple commits to a PR and confirm only the latest run executes

[claude]

Claude finished @carlos-alm's task —— View job

---

PR Review Complete ✅

Reviewed the concurrency group addition for the codegraph-impact workflow.

Root Cause Analysis

Problem Being Solved: The codegraph-impact.yml workflow was missing a concurrency group, causing every push to every open PR to queue a new run without cancelling stale ones. With many active PRs, this starved the GitHub Actions runner pool and left jobs queued for over an hour.

Why This Approach: Adds the missing concurrency control using the same proven pattern already implemented in ci.yml, embedding-regression.yml, and publish.yml. This is the standard GitHub Actions best practice for preventing resource waste.

Risk Assessment: LOW RISK — This is a hardening change that adds resource management without modifying workflow logic or relaxing any rules.

Backlog Compliance

• Zero-dep: ✓ — No runtime dependencies added, only GitHub Actions configuration
• Foundation-aligned: ✓ — Fully aligned with all principles, improves CI efficiency without external dependencies
• Problem-fit: 4/5 — Improves agent workflow by ensuring faster CI feedback, reducing iteration round-trips
• Breaking: No — Pure additive change, no user-facing behavior modification
• Tier: 1

Critical Concerns

None. This is a clean, minimal infrastructure improvement that follows established patterns.

Implementation verified:

• Correct scoping: codegraph-impact-${{ github.event.pull_request.number }} per individual PR
• Appropriate cancellation: cancel-in-progress: true cancels stale runs on new pushes
• Syntax consistency: Matches exact format used by other workflows in the repo

Final Recommendation

• Rating: ⭐⭐⭐⭐⭐ (5/5)
• Action: APPROVE
• Reasoning: Exemplary infrastructure fix that solves a real problem with minimal, clean implementation following established patterns. No concerns identified across any review phase.

---

[greptile-apps]

Greptile Summary

This PR adds a concurrency block to .github/workflows/codegraph-impact.yml — the only CI workflow that was missing one. Without it, every push to an open PR queued a new run without cancelling stale ones, starving the runner pool.

The fix uses group: codegraph-impact-${{ github.ref }} with cancel-in-progress: true, which exactly matches the pattern already used by ci.yml, embedding-regression.yml, and publish.yml. A prior review concern about using github.event.pull_request.number instead of github.ref was addressed in the latest commit (a9d00e0) — the key is now github.ref, making it consistent across all workflows and resilient to future push or workflow_dispatch triggers being added.

Confidence Score: 5/5

Safe to merge — a minimal, correct, and well-precedented change with no logic or data concerns.

The only change is a 4-line concurrency block that follows the identical pattern already proven across ci.yml, embedding-regression.yml, and publish.yml. The prior review concern about using pull_request.number vs github.ref was addressed before this review. No P0 or P1 findings remain.

No files require special attention.

Important Files Changed

Filename	Overview
.github/workflows/codegraph-impact.yml	Adds concurrency block with group: codegraph-impact-${{ github.ref }} and cancel-in-progress: true, matching the pattern used by all other CI workflows. Prior reviewer concern about using pull_request.number was resolved — now uses github.ref.

Sequence Diagram

sequenceDiagram
    participant Dev as Developer
    participant GH as GitHub Actions
    participant Runner as Runner Pool

    Note over Dev,Runner: Before fix — no concurrency group
    Dev->>GH: Push commit 1 to PR
    GH->>Runner: Queue run A (codegraph-impact)
    Dev->>GH: Push commit 2 to PR
    GH->>Runner: Queue run B (no cancellation)
    Dev->>GH: Push commit 3 to PR
    GH->>Runner: Queue run C (no cancellation)
    Note over Runner: All 3 runs queue up — pool starvation

    Note over Dev,Runner: After fix — concurrency group per github.ref
    Dev->>GH: Push commit 1 to PR
    GH->>Runner: Start run A (group: codegraph-impact-refs/pull/N/merge)
    Dev->>GH: Push commit 2 to PR
    GH->>GH: cancel-in-progress cancels run A
    GH->>Runner: Start run B (only latest runs)
    Dev->>GH: Push commit 3 to PR
    GH->>GH: cancel-in-progress cancels run B
    GH->>Runner: Start run C (only latest runs)

Loading

_{Reviews (2): Last reviewed commit: "fix: use github.ref for concurrency key ..." | Re-trigger Greptile}

[greptile-apps]

Inconsistent concurrency key vs. sibling workflows

The PR description says this "matches the pattern already used by ci.yml, embedding-regression.yml, and publish.yml", but those three all use github.ref as the key:

# ci.yml
group: ci-${{ github.ref }}

# embedding-regression.yml
group: embedding-regression-${{ github.ref }}

This PR uses github.event.pull_request.number instead. For a workflow that only triggers on pull_request the two are functionally equivalent (both are unique per PR), so this will work correctly as written.

However, using github.ref would be more consistent with the rest of the repo and more resilient — if a push or workflow_dispatch trigger is ever added, github.event.pull_request.number would resolve to an empty string and every such run would share a single unnamed group, potentially cancelling unrelated jobs.

Consider aligning with the existing pattern:

Suggested change

	group: codegraph-impact-${{ github.event.pull_request.number }}
	group: codegraph-impact-${{ github.ref }}

[carlos-alm]

Good catch — switched to github.ref to match the pattern used by ci.yml, embedding-regression.yml, and the other workflows. This is also more future-proof if additional triggers are ever added. Fixed in a9d00e0.

[carlos-alm]

@greptileai