release: 0.4.3 — publish to PyPI via trusted publishing - #30
Conversation
… the upload Adds PyPI trusted publishing over OIDC with build attestations, held closed behind the PYPI_PUBLISH_ENABLED repository variable. The distributions are handed to the publisher as their own artifact, so the checksums, SBOM and signatures stay release assets: the upload action rejects any non-distribution file in its payload. Adds release guards that assert the built distributions carry the tag version, and that the package reports it, before anything is signed or uploaded. Signed-off-by: Empire Labs Pty Ltd <narko4u@gmail.com>
f17677d to
062c008
Compare
![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: f17677d589
ℹ️ 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".
| - name: Fetch the distributions built by the release job | ||
| uses: actions/download-artifact@v4 | ||
| with: | ||
| name: dist | ||
| path: dist |
There was a problem hiding this comment.
On a workflow_dispatch run, the release job's checkout has no ref, so it builds the branch or tag selected when launching the workflow rather than the independent tag input. This download can therefore feed PyPI branch-built artifacts: if that ref contains untagged changes without a version bump, both version guards pass and the immutable PyPI release differs from the requested Git tag. Resolve and check out the validated input tag before building manual releases.
Useful? React with 👍 / 👎.
| fi | ||
| for f in "${files[@]}"; do | ||
| base="$(basename "$f")" | ||
| if ! grep -Eq "(^|[-_])${esc}([-_.]|$)" <<< "$base"; then |
There was a problem hiding this comment.
The regex treats ., _, and - after the expected text as valid boundaries, so a tag such as v0.4.3 accepts distributions named with versions like 0.4.3.post1 or 0.4.3.1. If pyproject.toml drifts to one of those versions while the source fallback remains 0.4.3, the second guard also passes and the workflow publishes the wrong immutable version under the tag; extract the wheel/sdist version field and compare it exactly instead.
Useful? React with 👍 / 👎.
1 participant
Adds PyPI publication, and the release guards that make it safe.
Publishing. A
publishjob uploads the distributions over GitHub OIDCtrusted publishing — no API token, no stored secret — with build attestations
attached, so a consumer can check provenance on the project page. It is held
closed behind the repository variable
PYPI_PUBLISH_ENABLED, so a tag pushnever leaves a failed run merely because the publisher is not configured yet.
Why the upload payload is its own artifact. The upload action rejects any
file in
packages-dirthat is not a wheel or a sdist:so the distributions are now kept as a separate artifact containing only the
wheel and the sdist. The checksums, SBOM and signatures remain release assets,
and a step in the publish job asserts the payload before the exchange with PyPI
rather than during it.
Guards. PyPI never allows a filename to be reused, so a distribution whose
version does not match its tag would permanently burn that version number on
mismatched code. Two steps now fail the run before anything is signed or
uploaded: the built distributions must carry the tag version, and the package
must report it — a source-tree fallback that drifts is invisible until a user
runs
--version, which is exactly how 0.2.1 shipped reporting 0.2.0.Verified locally on this branch:
python -m buildproducesmcp_evidence_validator-0.4.3-*PYTHONPATH=src python -m pytest -q— 50 passedPYTHONPATH=src python -c "import mcp_evidence_validator as m; print(m.__version__)"— 0.4.3Once merged I will tag the merge commit
v0.4.3. The PyPI pending publisher isalready registered for this repository,
release.ymland thepypienvironment.