Trusted Publisher setup fails because the secret doesn't start pypi?

[cricalix]

My understanding of the Trusted Publisher/OIDC approach is that I do not need to specify secrets; I set up the relevant pending publisher on PyPI, and changed my workflow to set id-token: write etcetera as documented at https://docs.pypi.org/trusted-publishers/using-a-publisher/

^ PyPI's pending publisher setup

I have a public repo set up with a "deploy" environment. Before I found out about Trusted Publisher, I added a PyPI secret to that environment (the history of the workflow will show where I was initially using the "pass a secret" approach).

My current workflow that failed: https://github.com/cricalix/python-lsp-pyre/blob/54789ccf5f87ebb526917a671678fc7e902a4db9/.github/workflows/python-publish.yml

The error: Warning: It looks like you are trying to use an API token to authenticate in the package index and your token value does not start with "pypi-" as it typically should. This may cause an authentication error. Please verify that you have copied your token properly if such an error occurs.

I have also tried removing the environment requirement on the PyPI side, and removed the environment setup from the workflow (main will show it). This fails the same way.

What elementary mistake am I making that's covered in the fine manual that I've read multiple times? :)

[cricalix]

I'll also add that I tested with a private repo against the PyPI test index, but in that case I used the with: password: syntax in the workflow, and that works just fine. I can, of course, do this for the package I want to publish to PyPI non-testing, but the docs implied the OIDC was was the current best practice.

[cricalix]

Of course, one posts a rubber-duck type question and then thinks of what the duck would say.

I moved the SHA foward to f47b347 which advocates for the OIDC approach, and it all works. I don't know where I got the previous SHA from - probably Github documentation/template?

[cricalix]

Given the main README advocates the OIDC approach, and the SHA approach, perhaps it should indicate a minimum SHA for getting the OIDC feature to work? And perhaps a map of SHA to release tag?

[webknjaz]

Yea.. I'm keeping @release/v1 in the docs specifically so that I don't have to change that line everywhere on every release. I expect that the end-users should consciously opt-in to using SHAs. I think you may've gotten that commit GHA from GitHub's built-in template, which for some reason they hard-coded to a really old version (hoping to fix that one day).

If you use commit SHAs, you should probably enable Dependabot — it knows how to bump them and adds an inline comment with an abbreviated human-readable tag name.

P.S. Sorry I missed this post months ago. The notification somehow didn't catch my eye..