mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 19:01:54 +00:00
kevinveenbirkenbachandClaude Opus 5
2cf3c5a708
The PR-close canceller had no concurrency group at all, so cancelling depended entirely on scripts/github/cancel/pull_request_runs.sh, which needs a runner before it can call the API. Runners were 20 minutes to 21 hours out, and run 31451265380 stayed alive that whole time. The canceller now joins the group entry-pr-change-orchestrate.yml renders for the same PR. GitHub clears the group when the run is created, before a runner is assigned, so the orchestrator dies immediately and the script becomes a backstop instead of the only path. The group spells pull_request out literally rather than interpolating github.event_name. This workflow is triggered by pull_request_target, so the interpolated form would join the twin the orchestrator's own job guards already skip on a same-repo PR and leave the working run untouched. A fork PR runs both twins; the pull_request_target one is still left to the script. The branch-delete sweep filtered runs by head_branch alone and shot this canceller mid-cancel. It now excludes the canceller's own path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Run Cancellation 🚫
Shell helpers that cancel in-progress GitHub Actions workflow runs in response to repository lifecycle events.
Scope 📋
This directory contains helpers invoked from workflows that listen on pull_request_target: closed, pull_request_target: converted_to_draft, and delete. The helpers call the GitHub Actions API to cancel runs whose original trigger is no longer relevant (a closed PR, a deleted branch). Helpers MUST NOT be called from workflows that have not received the corresponding lifecycle event, because cancelling unrelated runs would mask real failures and waste accumulated work.
For the workflow catalog that drives these calls see workflows.md.