v1.1.0 is tagged and the GitHub release carries both artifacts, but the publish-pypi job failed and PyPI is still on 1.0.2. Nothing partial was uploaded.
* `invalid-publisher`: valid token, but no corresponding publisher
(Publisher with matching claims was not found)
This is the first run of release.yml since it was added on 2026-06-26 — 1.0.x were published before it existed — so the trusted publisher has simply never been set up.
Why it matters right now
v1.1.0 fixes pitstop-mcp being dead on a fresh install: mcp 2.0.0 (2026-07-28) removed mcp.server.fastmcp, so pip install "pitstop-cli[mcp]" currently installs a pitstop-mcp that dies on import. Until PyPI has 1.1.0, that fix reaches nobody installing the normal way.
Fix (needs PyPI account access)
Add a trusted publisher at https://pypi.org/manage/project/pitstop-cli/settings/publishing/ with exactly the claims the failed run presented:
| field |
value |
| Owner |
galjos |
| Repository |
pitstop-cli |
| Workflow |
release.yml |
| Environment |
pypi |
Then re-run the release without retagging — the workflow takes an existing tag:
gh workflow run Release --repo galjos/pitstop-cli -f version=v1.1.0
publish-pypi sets skip-existing: true, so a re-run is safe.
v1.1.0is tagged and the GitHub release carries both artifacts, but thepublish-pypijob failed and PyPI is still on 1.0.2. Nothing partial was uploaded.This is the first run of
release.ymlsince it was added on 2026-06-26 — 1.0.x were published before it existed — so the trusted publisher has simply never been set up.Why it matters right now
v1.1.0 fixes
pitstop-mcpbeing dead on a fresh install:mcp2.0.0 (2026-07-28) removedmcp.server.fastmcp, sopip install "pitstop-cli[mcp]"currently installs apitstop-mcpthat dies on import. Until PyPI has 1.1.0, that fix reaches nobody installing the normal way.Fix (needs PyPI account access)
Add a trusted publisher at https://pypi.org/manage/project/pitstop-cli/settings/publishing/ with exactly the claims the failed run presented:
galjospitstop-clirelease.ymlpypiThen re-run the release without retagging — the workflow takes an existing tag:
publish-pypisetsskip-existing: true, so a re-run is safe.