mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-06 19:01:54 +00:00
kevinveenbirkenbachandClaude Opus 5
bf25eb2fc7
The sync job force-pushed the source repository's main onto this one so that `origin/main` would mean "upstream main" for the three consumers that diff against it. Carrying .github/workflows/** in that push is what GitHub refuses for an App token, and `workflows` is not a GITHUB_TOKEN permission scope, so the job needed an app installation that may write workflow files. Run 37169357364 showed the fork has no such secret at all. Nothing reads the pushed branch. push_ci_policy.sh, affected_roles.sh and new_roles.sh each fetch `origin main` into their own runner's clone before reading it, and no caller queries the branch through the API. Pointing those fetches at the configured source repository gives the same baseline read-only: no push, no credential, no app permission to widen. baseline_remote.sh resolves where that baseline comes from and keeps the normalization and the disabled-value list in one place: `origin` for the source repository itself, for a disabled sync and for a local clone without GITHUB_REPOSITORY, and the upstream fetch URL otherwise. The fetches now carry an explicit `main:refs/remotes/origin/main` refspec, which a URL needs and a remote name tolerates. The release guard keeps fetching `origin`: it asks whether a tag commit sits on this repository's own main, which is a different question from the diff baseline. Removed: the sync-main job, its `needs` edge, main_from_repository.sh and the directory that held it. test_diff_affected_roles.py copies only the script under test into its fixture, so it needed the new helper too. It also inherited the full environment, and a GITHUB_REPOSITORY present in CI would have sent the fixture's baseline fetch to the real upstream instead of its own bare remote: three of its five cases fail that way, and the run takes 24s instead of 0.3s because it goes to the network. The variable is now dropped alongside BASH_ENV. Verified by running the helper in all four contexts and affected_roles.sh from an empty refs/remotes/origin/main in a scratch clone as the fork, as the source repository and locally; each populated the ref and completed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
19 lines
1.3 KiB
Markdown
19 lines
1.3 KiB
Markdown
# GitHub Workflow Helpers 🔧
|
|
|
|
This directory holds the shell helpers that GitHub Actions workflows under [`.github/workflows/`](../../.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/](runner/) | Host-runner hygiene around image builds and deploys (disk, swap, Docker daemon, diagnostics). |
|
|
| [cancel/](cancel/) | Cancellation of in-progress workflow runs on PR-close and branch-delete events. |
|
|
| [cleanup/](cleanup/) | Scheduled repository maintenance that prunes stale GitHub resources. |
|
|
| [resolve/](resolve/) | Derivation of structured workflow inputs and outputs from repository state. |
|
|
| [update/](update/) | The scheduled `🔄 Update versions` pipeline (version bumps and PR open/refresh). |
|
|
| [release/](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](../../docs/contributing/tools/github/actions/workflows.md). For the repository Make target index see [make.md](../../docs/contributing/tools/make.md).
|