Repository navigation
ci: publish the package to PyPI and attach it to the release - #26
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). Two files spell that version out: pyproject.toml and `litearm.__version__`, which the README tells users to verify an install with. Rewriting only the first would ship a wheel whose metadata says one number while `litearm.__version__` still says 2.1.0. Both are asserted after the rewrite, because a sed that matched nothing would otherwise build whatever the file already said.
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. 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/:
litearm-pythonnexform-techlitearm-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.
The name is free on PyPI today. 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 whatever the file already says, and that version would be
the one published.
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.
Why the version is rewritten in two files
pyproject.tomlis not the only place the version is spelled out:src/litearm/__init__.pycarries__version__ = "2.1.0", and the README tellsusers to verify an install by reading it. Rewriting only
pyproject.tomlwouldship a wheel whose metadata says
1.2.0whilelitearm.__version__still says2.1.0.This does not resolve #17 and does not conflict with it: here the committed value
simply stops mattering for publishing, and the assertion keeps working unchanged
if
pyproject.tomlis later reset to the0.0.0placeholder.Testing
Replayed against a copy of this tree at HEAD, with a stand-in tag
v1.2.0:pip install -e ".[dev]" && pytest639 passed, 22 skipped in 64.36spython -m buildlitearm_python-1.2.0.tar.gz,litearm_python-1.2.0-py3-none-any.whllitearm.__version__1.2.0, matching the wheel metadata and the tagThe assertion was exercised on its failure path too: with the
__version__lineremoved, the step exits 1 rather than building the version already in the file.
Not tested here: the upload itself. It cannot run before the pending publisher
exists, and it cannot run before a tag exists.
Issues
Refs #17.