Move release onto py-canon - #2
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: cadc7c5a73
ℹ️ 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".
|
|
||
| jobs: | ||
| release: | ||
| uses: gojiplus/py-canon/.github/workflows/reusable-release.yml@v1 |
There was a problem hiding this comment.
When the release tag differs from v0.2.0, this workflow still builds package version 0.2.0: pyproject.toml declares a static version and src/streamcal/__init__.py hard-codes the same value, with no VCS-based version configuration. For example, a v0.3.0 push would create a GitHub release containing streamcal-0.2.0, and PyPI would reject that distribution if 0.2.0 is already published; configure dynamic tag-derived versioning or require and validate a matching static version before release.
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