New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ci/python-publish: bump, use trusted publishing #2345
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: William Woodruff <william@trailofbits.com>
xref #2344, github/docs#32146 CC @di @jhutchings1 CC @webknjaz as well, as the maintainer of |
@juliandunn @N-Usha FYI, I've been in discussion with @woodruffw, @di and the PyPI team about this. This change switches from using token based authentication to OIDC, and would be a great benefit to the security posture of this community. Let me know if you have any questions I can help with to get the review prioritized by Actions engineering. |
@@ -1,4 +1,4 @@ | |||
# This workflow will upload a Python Package using Twine when a release is created | |||
# This workflow will upload a Python Package to PyPI when a release is created | |||
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-python#publishing-to-package-registries |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's not against some policy, let's link https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/ (additionally) — we're trying to keep it up-to-date over in PyPUG, which often happens sooner than GH gets docs updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense to me. I'll defer to GH folks for any actual policy here 🙂
@woodruffw love that this is moving somewhere! Thank you for getting to this sooner than me :) I've been frustrated with how many people get pre-historic workflows by default and don't even know it... One extra thing to consider — it might be useful to also stick Sigstore signing right into the starter. OTOH, giving people a link to the guide might be an alternative. |
Linking some context: pypa/gh-action-pypi-publish#123 (comment) |
Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) <wk.cvs.github@sydorenko.org.ua>
I'd personally like to shy away from suggesting the Sigstore action here for now, if only because (with PEP 740) it'll become obsolete and integrated directly into the publishing flow 🙂 |
Signed-off-by: William Woodruff <william@trailofbits.com>
Signed-off-by: William Woodruff <william@trailofbits.com>
Signed-off-by: William Woodruff <william@trailofbits.com>
Signed-off-by: William Woodruff <william@trailofbits.com>
Signed-off-by: William Woodruff <william@trailofbits.com>
This should be good to go. I think it might make sense to review and land this before github/docs#32146, since the workflow changes here will need to be reflected there as well. |
Gentle ping for review here! (@jhutchings1 I'm calling in that promise 😉) |
Fixes #2344.
Tasks
For all workflows, the workflow:
.yml
file with the language or platform as its filename, in lower, kebab-cased format (for example,docker-image.yml
). Special characters should be removed or replaced with words as appropriate (for example, "dotnet" instead of ".NET").GITHUB_TOKEN
so that the workflow runs successfully.For CI workflows, the workflow:
ci
directory.ci/properties/*.properties.json
file (for example,ci/properties/docker-publish.properties.json
).push
tobranches: [ $default-branch ]
andpull_request
tobranches: [ $default-branch ]
.release
withtypes: [ created ]
.docker-publish.yml
).Some general notes:
actions
organization, or