Move release onto py-canon - #41
Conversation
Replaces a bespoke `python-publish.yml` with the same `release.yml` that calibre, simcheck, covered and preen run, calling py-canon's `reusable-release.yml`. The standing rule is that everything lives on py-canon and preen unless there is a reason not to, and this repo had no reason. What the bespoke workflow got wrong varies by repo but rhymes: this one could not be triggered by pushing a tag, which is how the rest of the fleet cuts a release. Nothing failed when you tried -- no workflow ran at all. The canon pattern also hash-pins its actions and adds `twine check` plus PEP 740 attestations on the uploaded artifact, none of which the hand-rolled version had. The publish step stays in this file rather than moving into py-canon, and that is deliberate: PyPI trusted publishing binds its OIDC claims to this repository's workflow path, so a reusable workflow cannot satisfy them. calibre documents the same exception in the same place. Tests are not re-run before publishing, also by design -- canon relies on CI having already run against the commit the tag points at. **This needs a change on PyPI to work.** The trusted publisher for this project names `python-publish.yml` and must be repointed at `release.yml`, or the next tag fails to publish. The workflow header says so too. actionlint clean. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2c0068c2f5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| with: | ||
| # `gh release create` fails when the release already exists, so create it | ||
| # only on the original tag push — not on a manual re-run of a released tag. | ||
| github-release: ${{ github.event_name == 'push' }} |
There was a problem hiding this comment.
When a tag-triggered run creates the GitHub release but the later PyPI upload fails, rerunning the workflow retains github.event_name == 'push', so this input enables gh release create again. Because the release already exists, the release job fails and needs: release prevents the publish retry; this also affects gh run rerun --failed, which reruns dependencies according to the CLI documentation. Use an existence/idempotency check or distinguish rerun attempts (for example via github.run_attempt) rather than relying only on the event name.
Useful? React with 👍 / 👎.
1 participant
Replaces a bespoke
python-publish.ymlwith the samerelease.ymlthat calibre, simcheck, covered and preen run, calling py-canon'sreusable-release.yml.The bespoke workflow could not be triggered by pushing a tag, which is how the rest of the fleet cuts a release — nothing failed when you tried, because no workflow ran at all.
Canon also hash-pins its actions and adds
twine checkplus PEP 740 attestations, none of which the hand-rolled version had.The publish step stays in this file rather than moving into py-canon, deliberately: PyPI trusted publishing binds its OIDC claims to this repository's workflow path, so a reusable workflow cannot satisfy them. calibre documents the same exception in the same place.
python-publish.ymland must be repointed atrelease.yml, or the next tag fails to publish. The workflow header says so too.Pairs with gojiplus/py-canon#18, which adds a test run before the build so a release cannot publish a commit whose suite is red.
actionlint clean.
🤖 Generated with Claude Code