mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-08 03:38:23 +00:00
kevinveenbirkenbachandClaude Opus 4.8
e55001e849
The roles updaters (Docker image versions, repository refs) opened a single combined PR for all role changes, and the jobs checked out the trigger commit (actions/checkout default), so updates were computed against a stale tree and could re-propose already-merged changes. - Check out 'ref: main' in all update jobs so the diff is always computed against the latest main tip at run time. - Add open_role_prs.sh: split the working-tree changes per role and open one isolated branch/PR per changed role, reusing open_pr.sh for the dedup/push/PR logic (new UPDATE_DEDUPE_PREFIX hook scopes the duplicate check per role; default preserves prior single-PR behavior for the skills job). - Wire the Docker and repository-refs jobs to open_role_prs.sh; skills stays a single PR. Branch: update/<type>-<role>-<date>-<fp>; commit/title gain a (<role>) suffix and a Scope line. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
GitHub Workflow Helpers 🔧
This directory holds the shell helpers that GitHub Actions workflows under .github/workflows/ call. Helpers are grouped by responsibility into subfolders so each workflow file pulls only from the clusters it actually needs.
Subfolders 🗂️
| Subfolder | Responsibility |
|---|---|
| runner/ | Host-runner hygiene around image builds and deploys (disk, swap, Docker daemon, diagnostics). |
| cancel/ | Cancellation of in-progress workflow runs on PR-close and branch-delete events. |
| cleanup/ | Scheduled repository maintenance that prunes stale GitHub resources. |
| resolve/ | Derivation of structured workflow inputs and outputs from repository state. |
| sync/ | Ref synchronization before workflow jobs derive CI scope from git history. |
| update/ | The scheduled Update: Versions pipeline (version bumps and PR open/refresh). |
| release/ | Release-time gates that decide whether a tagged commit may be released. |
A new helper MUST live in the subfolder that matches its responsibility. New responsibilities MAY motivate a new subfolder, but MUST NOT flatten back into the top level.
For the workflow catalog see workflows.md. For the repository Make target index see make.md.