This document is for maintainers. A release is published to PyPI by the
publish.yaml workflow when a tag vX.Y.Z is pushed.
PyPI already has 0.1.0 and 0.1.1, so the first version published by this workflow must be above 0.1.1.
The PyPI trusted publisher checks only the repository, the workflow file name and the environment name, and a tag push runs the workflow as it exists at the tagged commit. Steps 2 and 3 are therefore required: they decide who can publish.
- On PyPI, add a trusted publisher to the
supra-sdkproject (Manage, Publishing): ownerEntropy-Foundation, repositorysupra-python-sdk, workflowpublish.yaml, environmentpypi. - In the repository settings, create an environment named
pypiwith required reviewers. - In the repository settings, add a tag ruleset for
refs/tags/v*that restricts creation, update and deletion to maintainers.
The workflow uses PyPI trusted publishing; it needs no API token or repository secret. The publish action uploads attestations with the distributions.
Release tags go only on commits on master.
- Set
versioninpyproject.tomltoX.Y.Z. - Add the entry for
X.Y.ZtoCHANGELOG.md. - Merge the release pull request into
master. - Tag the commit that the release pull request produced on
masterand push the tag:git tag -a vX.Y.Z -m "supra-sdk X.Y.Z" <commit> && git push origin vX.Y.Z. - The workflow fails without publishing when the tag is not
vfollowed by the version inpyproject.toml, or when the tagged commit is not an ancestor oforigin/master. These checks catch mistakes; the environment reviewers and the tag ruleset are what restrict publishing. A reviewer approves thepypienvironment deployment. - Create the GitHub release for the tag, with the
CHANGELOG.mdentry as its notes. The workflow does not create it. - Check that the new version is on PyPI.
The documentation site is built from master by the docs workflow and shows the version of the installed package.