Files
computer-playbook/scripts/github/update
kevinveenbirkenbachandClaude Opus 5 5e6884b16d feat(update): keep pinned pip requirements from ageing unnoticed
The version cron updates docker image tags and repository refs, and tests/external/update covers docker, addons and repository. Neither sees a version inside an Ansible task variable, and dependabot reads pyproject.toml rather than roles/. A pin set once therefore froze and nothing thawed it: backup-docker-to-local has not moved since it was written, and the automtu pin one commit back would have gone the same way.

utils/update/pip mirrors the docker module: collect the pins, ask PyPI, rewrite in place. Only exact == pins are collected, because a range or a VCS reference states an intent an updater must not overrule. The external check warns rather than fails, like its docker sibling, so a slow PyPI cannot redden a run and a release the repository has deliberately not taken is not a regression.

The cron job is the docker job with one script swapped, so a changed pin arrives as its own PR under update/pip-pins.

Executed: the collector finds both pins in the repository; a synthetic file rewrites from 1.0.0 to 1.1.1 with the indent, quoting and neighbouring line untouched; automtu==1.0.0 would be reported while a bare name and a git+ reference are passed over.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-09 01:44: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.