arckit-cli on PyPI is stuck at 6.4.1 while the repo ships 6.11.0. pip install arckit-cli has been serving a months-old CLI to anyone not installing from the git URL.
The job has never worked
This is not a regression. The publish job was added at v6.8.0 by #730 / #731, specifically to fix the "publishing is a manual step so it stopped happening" problem, and it has failed on every release since:
| Release |
Date |
Publish job |
| v6.8.0 |
2026-08-04 |
❌ |
| v6.9.0 |
2026-08-13 |
❌ |
| v6.10.0 |
2026-08-18 |
❌ |
| v6.11.0 |
2026-08-19 |
❌ |
The release job itself succeeds and the GitHub Release is created each time, so a red Release workflow run does not mean the release failed — it means this one job did. That is part of why it went unnoticed.
The error
Trusted publishing exchange failure:
* `invalid-publisher`: valid token, but no corresponding publisher
(Publisher with matching claims was not found)
The OIDC token mints correctly. PyPI simply has no Trusted Publisher entry matching the claims the workflow presents.
The fix — PyPI-side, not repo-side
Nothing in this repository can resolve this. Someone with PyPI access to the arckit-cli project needs to add a Trusted Publisher under Publishing → GitHub Actions, matching all four values exactly:
Owner: tractorjuice
Repository: arc-kit
Workflow: release.yml
Environment: pypi
The Environment: pypi line is the one most likely to be missed. The job declares environment: pypi, and a publisher configured without an environment will not match a request that declares one.
Verifying the fix
There is no need to cut a release to test it. Once the publisher exists, re-run the failed Publish to PyPI job from any of the four failed runs above — the workflow sets skip-existing: true, so a re-run is a no-op if the file is already there and a real publish if it is not.
Already done
#813 added a dated status block to the job in release.yml recording the failure, the versions affected, and the exact claims that must match, so each release stops rediscovering it. The job is deliberately not silenced or continue-on-error'd: it should keep failing loudly until the publisher exists.
Split out of #466 (item 17's investigation) so it is not lost when that tracker closed.
arckit-clion PyPI is stuck at 6.4.1 while the repo ships 6.11.0.pip install arckit-clihas been serving a months-old CLI to anyone not installing from the git URL.The job has never worked
This is not a regression. The publish job was added at v6.8.0 by #730 / #731, specifically to fix the "publishing is a manual step so it stopped happening" problem, and it has failed on every release since:
The
releasejob itself succeeds and the GitHub Release is created each time, so a red Release workflow run does not mean the release failed — it means this one job did. That is part of why it went unnoticed.The error
The OIDC token mints correctly. PyPI simply has no Trusted Publisher entry matching the claims the workflow presents.
The fix — PyPI-side, not repo-side
Nothing in this repository can resolve this. Someone with PyPI access to the
arckit-cliproject needs to add a Trusted Publisher under Publishing → GitHub Actions, matching all four values exactly:The
Environment: pypiline is the one most likely to be missed. The job declaresenvironment: pypi, and a publisher configured without an environment will not match a request that declares one.Verifying the fix
There is no need to cut a release to test it. Once the publisher exists, re-run the failed
Publish to PyPIjob from any of the four failed runs above — the workflow setsskip-existing: true, so a re-run is a no-op if the file is already there and a real publish if it is not.Already done
#813 added a dated status block to the job in
release.ymlrecording the failure, the versions affected, and the exact claims that must match, so each release stops rediscovering it. The job is deliberately not silenced orcontinue-on-error'd: it should keep failing loudly until the publisher exists.Split out of #466 (item 17's investigation) so it is not lost when that tracker closed.