Create a workflow to build and publish strix-agent to PyPI on tag, via Trusted Publishing.
Benefits:
- Cutting a release becomes one action. Today it's push the tag, then remember to build and upload the sdist and wheel. There's no script for that second half (
scripts/ has build.sh, docker.sh and install.sh). Automate it and the tag is the only step. 1.2.0 and 0.8.2 have tags and GitHub releases but aren't on PyPI today, unless those were pulled on purpose.
- The README badge and the pipx install path both read from PyPI.
README.md renders a PyPI version badge, docs/quickstart.mdx offers pipx install strix-agent, and update_check.py polls PyPI's info.version to tell pip, pipx and uv users an update exists. When PyPI trails a tag, the badge is wrong and those users are never told a release shipped.
- No long-lived API token anywhere. Not in GitHub Secrets, not on a laptop. The workflow presents a GitHub OIDC token, PyPI exchanges it for a project-scoped API token that's good for 15 minutes, and nothing durable is stored. The registration ties publishing rights to this repo, this workflow file and the environment name, which has to match on both sides. Once it's registered you can revoke whatever token is in use today.
- PEP 740 attestations come with it. Each published file traces back to a commit in this repo. Nothing in pip or uv verifies them yet. Of the packages I checked, semgrep, bandit, checkov, pytest, pipx and openai-agents all publish with attestations.
What it takes. Two parts: a job in build-release.yml, and a registration on pypi.org that only a project owner can do. build-release.yml never produces an sdist or wheel. It runs uv run pyinstaller to freeze a standalone binary per platform. So this adds a job rather than editing one:
publish-pypi:
needs: build
if: startsWith(github.ref, 'refs/tags/') # not on a workflow_dispatch from a branch
runs-on: ubuntu-latest
environment: pypi
permissions:
contents: read
id-token: write # OIDC for Trusted Publishing
steps:
- uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4.4.0
with:
persist-credentials: false
- uses: astral-sh/setup-uv@d4b2f3b6ecc6e67c4457f6d3e41ec42d3d0fcb86 # v5.4.2
with:
enable-cache: false
- run: uv build
- uses: pypa/gh-action-pypi-publish@ba38be9e461d3875417946c167d0b5f3d385a247 # v1.14.1
Then on pypi.org, register a Trusted Publisher on the strix-agent project for usestrix/strix, workflow build-release.yml, environment pypi (docs). Only an Owner on Pypi can do this.
Happy to open the PR for the workflow side if that'd help, with a check that the tag matches [project].version if you want one. #862 was mine.
Create a workflow to build and publish
strix-agentto PyPI on tag, via Trusted Publishing.Benefits:
scripts/hasbuild.sh,docker.shandinstall.sh). Automate it and the tag is the only step.1.2.0and0.8.2have tags and GitHub releases but aren't on PyPI today, unless those were pulled on purpose.README.mdrenders a PyPI version badge,docs/quickstart.mdxofferspipx install strix-agent, andupdate_check.pypolls PyPI'sinfo.versionto tell pip, pipx and uv users an update exists. When PyPI trails a tag, the badge is wrong and those users are never told a release shipped.What it takes. Two parts: a job in
build-release.yml, and a registration on pypi.org that only a project owner can do.build-release.ymlnever produces an sdist or wheel. It runsuv run pyinstallerto freeze a standalone binary per platform. So this adds a job rather than editing one:Then on pypi.org, register a Trusted Publisher on the
strix-agentproject forusestrix/strix, workflowbuild-release.yml, environmentpypi(docs). Only an Owner on Pypi can do this.Happy to open the PR for the workflow side if that'd help, with a check that the tag matches
[project].versionif you want one. #862 was mine.