Files
computer-playbook/scripts/github/update
kevinveenbirkenbachandClaude Opus 5 71888d86af refactor(ci): prefix workflows by trigger
The workflow directory mixed entry points, reusable stages and scheduled jobs into one flat list sorted by topic, so the first question about any file - what starts it - was the one the name did not answer. Every workflow now carries one of three prefixes, derived from its on: block: cron- for a schedule trigger, call- for one only reachable through workflow_call, entry- for everything a repository event or a human starts. Scheduled workflows additionally carry an alarm clock as the first character of their name.

Two lints keep it that way. One derives the expected prefix from the triggers and compares it against the file name; it flagged all 17 offenders before the rename and none after. The other resolves every .github/workflows/<file> string in the repository against the directory, which is what a rename silently breaks in Markdown links, Python constants and shell API URLs alike.

Renaming pulled 69 pre-existing comments into the comment lint's changed-file scope. The vendored CodeQL template got the nocheck marker its scorecard sibling already carried, two workflow headers moved above name: where they count as file headers, and the remaining banners were deleted.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-07 17:05:51 +02:00
..
…

Update Pipeline 🔄

Shell helpers that drive the scheduled Update: Versions workflow.

Scope 📋

This directory contains the helpers invoked by cron-update.yml to bump pinned upstream versions and open a pull request once per day. The helpers are thin wrappers: the image-version and repository-ref bumpers delegate to Python CLIs under cli/contributing/ that scan roles/*/meta/services.yml and rewrite version pins in place; the PR-open helper commits, force-pushes the update branch, and creates or refreshes the PR via gh. Helpers MUST NOT be called from workflows other than ⏰ Update: Versions; the CI_ENABLE_AUTO_UPDATES gate is enforced once, at the workflow's job level, and bypassing it from another caller would create PRs even when auto-updates are intentionally disabled.

Each shim MUST resolve the repository root relative to its own location so it can run from any working directory, MUST forward arguments to the underlying CLI so --dry-run and similar flags keep working from the shell, and MUST exit non-zero on CLI failure so the workflow surfaces the error.

For the workflow catalog see workflows.md. For the repository variable that gates the workflow see configuration.md. For the App-token secrets that the PR-opening step requires see secrets.md.