Supersedes v1.4.0, whose fix did not work.
v1.4.0 moved tag creation to the git-data API on the belief that it sidesteps GitHub's workflow-file protection. It does not — creating a ref at a commit whose .github/workflows differ from the default branch fails over the API exactly as over git push, reported less helpfully as Resource not accessible by integration. The constraint is the token, not the transport, and GITHUB_TOKEN cannot hold the workflow scope by any route.
The real problem
Since v1.1.1 the tag landed on each image's build commit. Any CI change merged after the last image build makes that commit's workflows differ from the default branch — and that is exactly when someone reaches for a release. VirtualWindow hit it on both attempts.
The change
Provenance stops living in where the tag points and moves into content:
- The tag lands on the ref being released, whose workflows are the default branch's by definition, so the restriction can never apply.
- The tag message and release body name the build commit of every image:
ghcr.io/cshuttle/virtualwindow:v1.1.0—sha256:…, built from4749ed9
"Which commit is this version?" is still answerable — from the release rather than the ref. The provenance guard is untouched: every image is still proven to have been built from this branch's history.
The rejected alternative was a workflow-scoped PAT in every releasing repo — a long-lived credential in eight repos, in an estate working to retire the one it has.
Minor: behaviour change; callers do nothing.