fix: publish only reviewed commits that passed CI

[AlexeyShalaev]

The problem

Two issues, one job. #10: any branch could publish any ref. The pypi environment had no deployment policy, and the dispatch tag input was checked out as given, whether it was a branch, a SHA or any tag. #11: publish started when Release Please finished, minutes before CI on the same commit was done, and it rewrote __version__.py from the tag. A tag that disagreed with the committed version therefore shipped under the tag's version without any error. Both come down to the check job deciding what gets published, so they share this PR.

The decision

The boundary is the environment, and it admits master only. setup_repo.py now creates pypi with a custom deployment policy holding one branch policy for the default branch, and removes any other policy it finds, the same way it replaces the ruleset as a whole. Both triggers already run with master as their ref: workflow_run always runs on the default branch, and a dispatch runs from master. So the workflow file that decides what reaches PyPI is always the reviewed one on master. A dispatch from another branch is refused the environment by GitHub, whatever that branch's publish.yml says. This is a repository setting. The YAML also rejects a non-master dispatch in check, but only to give a readable error; it does not protect anything.

The tag input stays, but it is only data. It reaches the shell through env:. It has to match the release tag pattern, exist as a tag, and point at a commit on master. The publish job checks out the SHA that check resolved, so moving the tag between the two jobs changes nothing.

CI on the released commit gates the release. When there is a release tag, check finds the push run of ci.yml for that SHA, waits for it, and fails unless it ends success. If there is no CI run, that is an error. A dispatch goes through the same wait. Ordinary pushes to master without a tag skip the wait.

The version comes from the commit. The "Set version from release tag" step is gone. check compares the tag's version with __version__ in the tagged commit and fails with both values when they differ. hatch builds from that file, so the artifacts always carry the committed version.

id-token: write moved from the workflow to the publish job. check has contents: read and actions: read.

What I rejected

• Dispatching from the tag (--ref <tag>) with the environment admitting <slug>-v* tags, as publish.yml can publish from any branch or tag: the pypi environment has no deployment policy and the tag input is used as-is #10 proposes. The tag's own copy of publish.yml would then run. Anyone who can push a matching tag could point it at a commit whose workflow skips every check, so the policy would need a tag ruleset, with a bypass for whatever creates release tags (GITHUB_TOKEN today, an App after CI never runs on Release Please PRs, so every release needs a manual close and reopen #12). If master is the only ref that can deploy, tags need no protection for publishing to be safe.
• Triggering publish on workflow_run of CI. CI and Release Please start from the same push, so publish would depend on which one happens to finish first, and a dispatch would still need its own wait.
• Required reviewers on pypi. Every automated release would wait for a person.

Evidence

Render of origin/master against a render of this branch (copier copy --defaults, demo-lib):

• before: id-token: write at workflow level. check and publish check out inputs.tag / needs.check.outputs.tag as given. A "Set version from release tag" step is there.
• after: none of those. actionlint 1.7.12 (with shellcheck) is clean on all four generated workflows.

The "Resolve the release tag" step, taken from the rendered file and run with bash -eo pipefail (as Actions runs it) in a git repo with a bare origin:

dispatch, good tag:             Will publish demo-lib-v0.0.0 (75e7883…)                 exit=0
dispatch, tag != committed:     ::error::demo-lib-v9.9.9 is version 9.9.9, but demo_lib/__version__.py at 75e7883… says '0.0.0'   exit=1
dispatch, tag off master:       ::error::demo-lib-v0.0.1 points at 202e61c…, which is not on master   exit=1
dispatch, a branch as tag:      ::error::'master' is not a release tag of this project   exit=1
dispatch, a SHA as tag:         ::error::'75e7883…' is not a release tag of this project   exit=1
dispatch, no such tag:          ::error::There is no tag demo-lib-v1.2.3                 exit=1
dispatch, shell in input:       ::error::'v1$(touch /tmp/pwned)' is not a release tag of this project   exit=1
dispatch from scratch branch:   ::error::Publish from master, not refs/heads/scratch: …  exit=1
workflow_run, release commit:   Will publish demo-lib-v0.0.0 (75e7883…)                  exit=0
workflow_run, untagged commit:  No release tag on 9b33f8d…, nothing to publish.          exit=0

The "Wait for CI" step, run read-only against real clientwright runs:

clientwright 0.5.0 release commit e2699c9:  Waiting for …/actions/runs/34977035143 / CI passed   exit=0
clientwright master commit b82e2dd:         ::error::CI on b82e2dd… ended 'failure'            exit=1
a SHA with no push CI run:                  ::error::No CI run for 0000000… on master          exit=1

With a fake gh, a run that only appears on the third listing and stays in_progress for two polls is waited out and passes.

setup_repo.py with a fake gh that records the writes:

fresh repo:      PUT environments/pypi {"deployment_branch_policy": {"protected_branches": false, "custom_branch_policies": true}}
                 POST environments/pypi/deployment-branch-policies {"name": "master", "type": "branch"}
already set:     PUT only
drifted:         removing deployment policy tag '*' / branch 'release/*'  (DELETE 2, DELETE 3)

The response shapes are the ones clientwright's github-pages environment returns today ({"custom_branch_policies":true,"protected_branches":false} and branch_policies[].{id,name,type}). The generated gate on the render: ruff check / ruff format --check / mypy clean, 1 test passed, uv build built both files.

After merging

Re-run setup_repo.py on each library to set the policy. Until a library runs it, its pypi environment stays open to any branch, as it is today.

Closes #10
Closes #11