Upload to production PyPI from this workflow (needs .github#53 and a new publishing tag first) - #151
Merged
Merged
Conversation
v0.6.1's PyPI upload failed with invalid-publisher: PyPI matches the Trusted Publisher against the workflow that runs the upload job, and that job ran inside PyDevices/.github's reusable coordinator. The upload is now the pypi job here, fed by the coordinator's pypi-publish and dist-artifact outputs, and report-pypi tells Release Health how it went. id-token:write is granted to that one job instead of the whole workflow. Both reusable refs are publishing-vNEXT, a placeholder for the first publishing tag cut after the .github change; it must be replaced before merge. docs/building-wheels.md said 21 wheels and publishing-v8; it is 18, and the pin is named where it lives.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Don't merge this until .github#53 is merged and a new publishing tag exists. Both reusable refs here say
publishing-vNEXT, a placeholder. As written, the publish workflow fails at startup.v0.6.1 failed at PyPI with
invalid-publisher(run 36131566669). The upload ran inside PyDevices/.github's reusable workflow, and PyPI matches the Trusted Publisher against the workflow that runs the upload job, so it could never matchpublish-release-packages.ymlhere. The PyPI side is set up right. .github#53 has the full story.This PR moves the upload into this file:
pypiruns when the coordinator'spypi-publishoutput istrue. It downloads the coordinator'sdist-artifactand uploads with Trusted Publishing, through thepypienvironment (your approval,v*tags only).id-token: writeis granted to this one job now, not to the whole workflow.report-pypisends the PyPI result to Release Health. The coordinator's report now sayspendingfor PyPI, and this fills it in.docs/building-wheels.mdsaid 21 wheels andpublishing-v8. It's 18, and the pin is now described where it lives.Order
dotgithub, runscripts/cut_publishing_tag.sh 12(or the next free number).publishing-vNEXTrefs with that tag, delete the two placeholder comments, and merge.The next final audiodsp release is the first to go through. v0.6.1 can't be retried this way: the
pypienvironment only deploys fromv*tags, and a dispatch onv0.6.1runs this file as it was at that tag. Either wait for the next release, ortwine uploadv0.6.1's Release assets by hand, the way 0.6.0 was parked.Moving from v8 to the new tag also brings cibuildwheel 4.2.1 and setup-java v6 to the builds. Nothing else in audiodsp's path changes.
Checked
actionlint 1.7.12 is clean. I also linted this file against .github#53's reusables resolved locally, which checks every output and input name, and a planted misspelling of
dist-artifactwas caught.scripts/check_attribution.pypasses. Nothing ran on GitHub.