[astrojuanlu]

Propagates template updates to the plugin repositories automatically.

Why

Plugin repos are generated from this template via Copier and record the template version in .copier-answers.yml. The template auto-tags every merge to main, so scaffolding improvements (issue templates, CI workflows, README wording) are immediately available as a tag — but without automation, propagating one means manually opening a PR per plugin repo: repetitive and easily forgotten, letting repos drift apart.

Design

• meta plugins/ is the source of truth for the plugin list. The workflow reads the directory listing via the API at runtime; every <plugin_name>-obs-studio.json record maps to <plugin_name>-obs-studio-snap. Rejected alternative: an org API repo listing (would match non-plugin repos and duplicate knowledge already in meta).
• One workflow, in the template repo (propagate.yaml + stdlib-only driver). Triggered by workflow_run after the auto-tag workflow, plus workflow_dispatch with an explicit tag for manual runs. Rejected alternative: per-repo dispatcher workflows (more moving parts).
• copier update (three-way merge), not re-render. Plugin repos carry hand-tuned build recipes that must survive updates; conflicts surface in the PRs for human resolution.
• Idempotent and observable. Skips repos already on the target tag (per .copier-answers.yml), skips existing template-update-<tag> branches/PRs, reports record-without-repo as skip (not fail), and writes a per-plugin summary table to the run summary.
• Commit identity and signing. Commits are authored by the obs-plugins-snaps-bot machine user (noreply email matches the account holding the SSH signing key, registered as a signing key) and signed with the CI_SSH_SIGNING_KEY repo secret, so they show as Verified. PRs are opened by the App.
• Permissions. The App needs contents: write, pull_requests: write, workflows: write (the latter because template updates modify .github/workflows/* files, which GitHub gates separately); template carries the APP_CLIENT_ID variable, APP_PRIVATE_KEY and CI_SSH_SIGNING_KEY secrets.

What this PR contains

.github/workflows/propagate.yaml — the workflow described above: resolve latest v* tag → list plugin records in meta → per repo: skip guards → copier update --defaults --vcs-ref <tag> → commit (signed, authored by the machine user) → push branch → open PR with a body listing the template commits and files in range, plus the repo-level diffstat of what actually got rendered.

.github/scripts/propagate.py — stdlib-only driver (urllib, subprocess, tempfile; no extra CI deps): per-plugin error isolation, template-change summary via the compare API, repo diffstat, PR creation, $GITHUB_STEP_SUMMARY table (skipped / updated / missing repo / failed).

pyproject.toml — ruff per-file ignores for the shipped driver.

Verification done locally

• Plugin-list query against the live meta API returns all 4 plugins
• copier update --defaults --vcs-ref v0.0.6 on a fresh clone of source-record-obs-studio-snap: clean three-way update (.copier-answers.yml → v0.0.6, new bug.yml)
• PR-body rendering (commit list + file list from the compare API, repo diffstat) against live data
• ruff check + ruff format --check clean; pytest 26 passed

First run

After merge, trigger via Actions → Propagate template updates → Run workflow with tag v0.0.6 (the workflow_run trigger only fires on the next tag). Expected: 4 update PRs (source-record, distroav, ndi-runtime, advanced-scene-switcher), each containing the v0.0.6 scaffolding plus the .copier-answers.yml bump.

Assisted-by: OpenRouter:z-ai/glm-5.3-flash pi