Repository navigation
ci: publish the package to PyPI and attach it to the release - #69
Merged
Merged
Conversation
The release workflow was the source-only stub: it tagged and created the GitHub release but shipped no package. Add the two jobs the template provides for a repository that publishes. `publish` uploads the sdist and the wheel to PyPI through Trusted Publishing (OIDC), so this repository stores no API token at all. `package` attaches the same two files to the GitHub release. Both jobs rewrite the version from the tag inside the workspace, because semantic-release never commits it back (AGENTS.md §3), and assert the rewrite before building: a sed that matched nothing would otherwise build 0.0.0, the placeholder. `litegrip.__version__` needs no equivalent step, because it reads the installed distribution metadata, so the wheel cannot disagree with itself.
The release workflow only builds after a merge to the default branch, by which point semantic-release has already created the tag and the GitHub release. A build that fails there leaves a version that exists as a tag and nowhere else, and that number cannot be reused. Build in the pull request gate as well, so a broken pyproject.toml is stopped before the merge. The version is deliberately left alone here: what this checks is that the tree as committed builds.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The release workflow was still the source-only stub synced from
repo-template:it versioned, tagged and opened a GitHub release, but shipped no package — while
the README has been telling readers the package is not on PyPI yet. This PR adds
the two jobs the template provides for a repository that publishes, so a merge to
mainends with the SDK on PyPI and the same two files on the release.PyPI has to be told about this repository before this merges — see below.
Before merging
Register a pending publisher at https://pypi.org/manage/account/publishing/:
litegripnexform-techlitegrip-pythonrelease.ymlUntil that exists the
publishjob is refused and goes red. No secret is neededand none should be created: the job authenticates with a short-lived OIDC token,
so there is no long-lived credential to leak or rotate.
litegripis free on PyPI today, and it is the namepyproject.tomland theREADME already use. The first release after this merges publishes
v1.2.0orv1.1.2, whichever the merge prefix earns.Changes
release.yml— newpublishjob: builds the sdist and wheel, uploads both toPyPI through Trusted Publishing.
release.yml— newpackagejob: attaches the same two files to the GitHubrelease. It repeats the build instead of sharing it with
publishon purpose;the template's jobs are independent siblings, and coupling them would mean
deleting one breaks the other.
release.yml— both jobs rewrite the version from the tag in the workspaceonly, then assert the rewrite before building. A
sedthat matched nothingwould otherwise build
0.0.0, the placeholder, and publish a version nobodychose.
ci.yml— build the package on pull requests. This is the second commit and canbe dropped on its own if you would rather not have it.
litegrip.__version__needs no second rewrite step, because it reads the installeddistribution metadata rather than repeating the number. The wheel therefore cannot
disagree with itself.
Testing
Replayed against a copy of this tree at HEAD, with a stand-in tag
v1.2.0:python3 -m unittest discover -s tests -t testsRan 466 tests in 11.446s—OK (skipped=12)python -m buildlitegrip-1.2.0.tar.gz,litegrip-1.2.0-py3-none-any.whllitegrip.__version__1.2.0, matching the wheel metadata and the tagThe assertion was exercised on its failure path too: with the
versionlineremoved, the step exits 1 rather than building the placeholder.
Not tested here: the upload itself. It cannot run before the pending publisher
exists, and it cannot run before a tag exists.
Issues
None — no open issue in this repository covers it.
README.mdline 24 says thepackage is not on PyPI yet, which stops being true at the first publish; it is
left alone here because it is accurate until then, and is worth updating in the
pull request that follows the first release.