[Fleet Monitor] petry-projects/ContentTwin — .github/workflows/pr-auto-review.yml

[don-petry]

🟠 DEGRADED: petry-projects/ContentTwin / .github/workflows/pr-auto-review.yml

Metric	Value
Failure Rate	26.3% (5 / 19 runs)
Status	DEGRADED
p50 Duration	293s
p95 Duration	411s
Successful Runs	14
Cancelled Runs	0

Workflow: .github/workflows/pr-auto-review.yml

Last updated by Fleet Monitor run on 2026-06-18.
Threshold: failure rate > 10% over the monitored window.

[don-petry]

Dev-Lead Implementation Plan

Issue: #274 — [Fleet Monitor] petry-projects/ContentTwin — .github/workflows/pr-auto-review.yml

Scope

The 26.3% "failure rate" is driven entirely by action_required runs — pull_request-triggered runs from rapid github-actions[bot] PR pushes that GitHub holds pending approval. Fleet Monitor counts action_required as a failure. Fix mirrors #263 (sonarcloud.yml): add a top-level concurrency block so superseded runs on the same ref are cancelled (counted separately, not as failures) instead of piling up pending.

Root-cause evidence

• Last 60 runs: 50 success, 10 action_required, 0 actual failure.
• All action_required runs are pull_request events triggered by github-actions[bot] with 0s duration.
• fleet_monitor.sh:123 classifies action_required as failing; cancelled is excluded (:125).

Implementation Checklist

• Add a top-level concurrency block to .github/workflows/pr-auto-review.yml (group: ${{ github.workflow }}-${{ github.ref }}, cancel-in-progress: true). No trigger or permissions changes (per stub header constraints).

Tests to Write

• scripts/tests/pr-auto-review-workflow.bats — assert workflow file exists, is valid YAML, declares a concurrency block, group keys on github.ref, and cancel-in-progress: true (mirrors sonarcloud-workflow.bats).

Test Command

bats scripts/tests/

[don-petry]

Dev-Lead: Implementation Complete

Plan Execution

• Diagnosed root cause: the 26.3% "failure rate" is entirely action_required runs (0 real failure conclusions in the last 60 runs). They come from rapid github-actions[bot] pull_request pushes held pending approval; fleet_monitor.sh:123 counts action_required as failing while cancelled is excluded (:125).
• Wrote failing bats tests for the concurrency guard (red), then implemented the fix (green).
• Added a top-level concurrency block to .github/workflows/pr-auto-review.yml — no trigger or permissions changes (per the thin-caller stub header constraints). Mirrors the [Fleet Monitor] petry-projects/ContentTwin — .github/workflows/sonarcloud.yml #263 fix to sonarcloud.yml.

Test Results

=== FULL BATS SUITE (bats scripts/tests/) ===
1..18
ok 8 pr-auto-review workflow file exists
ok 9 pr-auto-review workflow is valid YAML
ok 10 pr-auto-review workflow declares a concurrency block
ok 11 pr-auto-review concurrency cancels in-progress runs
ok 12 pr-auto-review concurrency group is keyed per ref
ok 13 pr-auto-review still delegates to the org reusable workflow
... (all 18 pass, incl. existing sonarcloud + apply-repo-settings suites)

=== DEV-LEAD LINT (.dev-lead/scripts/dev-lead-lint.sh) ===
  [lint] shellcheck on 2 file(s)...
  [lint] all checks passed

Files Changed

• .github/workflows/pr-auto-review.yml: added a top-level concurrency block (group: ${{ github.workflow }}-${{ github.ref }}, cancel-in-progress: true) so superseded same-ref runs are cancelled instead of piling up as action_required. Cancelled runs are not counted as failures by Fleet Monitor.
• scripts/tests/pr-auto-review-workflow.bats: new test file asserting the workflow exists, is valid YAML, declares a per-ref concurrency group with cancel-in-progress: true, and still delegates to the org reusable workflow.

Notes

• Stub-constraint compliance: trigger event types and the job-level permissions: block are unchanged; only a concurrency block was added (neither is in the stub's "MUST NOT change" list).
• Trade-off (same as [Fleet Monitor] petry-projects/ContentTwin — .github/workflows/sonarcloud.yml #263): for workflow_run events on main, cancel-in-progress may cancel an in-flight readiness check, but the newer run re-evaluates readiness, so the latest wins and cancellations are excluded from the failure metric.
• No actual workflow failure conclusions exist — this is a metric-inflation fix, consistent with the sonarcloud precedent.