Upgrade PyPI upload workflow to use Trusted Publishing (#4589)

[ahmed5145]

Fixes #4589

This PR upgrades the PyPI publishing workflow to use Trusted Publishing instead of token-based authentication. This change:

• Improves security by using OpenID Connect (OIDC) instead of long-lived tokens
• Removes the need for maintaining PyPI tokens in GitHub secrets
• Uses the official PyPA publishing action

Changes made:

• Added id-token: write permission for OIDC authentication
• Changed environment name to 'release'
• Switched to pypa/gh-action-pypi-publish action
• Removed twine dependency

Required actions after merging:
The repository maintainers will need to:

1. Configure Trusted Publishing in PyPI for the black project:
   • Go to https://pypi.org/manage/account/publishing/
   • Configure with:
     • Owner: psf
     • Repository: black
     • Workflow name: Build and publish
     • Environment: release
2. Create a 'release' environment in the GitHub repository settings
3. Remove the existing PyPI token from GitHub secrets (after verifying the new setup works)

[cooperlees]

Cool - TIL there is something more official than what I long ago cooked up at a GitHub conference when Actions were announced. Let's make CI happy and this feels the right way to go to me. I'll be copying for my other projects too :)

[ahmed5145]

Happy to hear that, please feel free to use across. It's quite impressive that you were there during the announcement of Actions.

It seems that there is an issue with the CI workflow in the PR. The diff-shades-comment job is failing because it cannot find the .pr-comment.json artifact. This artifact is expected by the comment-details command in the diff_shades_gha_helper.py script.

I've reviewed the script and it seems like the artifact is not being generated or uploaded in the diff-shades workflow.
Could you provide guidance on how this artifact should be generated? Are there any known issues with the current CI setup that might be causing this?
Or if I am getting this completely wrong.
Thank you for your assistance!

[cooperlees]

CI seems to be working here - Is it just failing locally for you?

This looks good - I would imagine our next test run of this would confirm? Should we force run the skipped tests maybe?

Thoughts here other maintainers?

[JelleZijlstra]

This seems fine but it will need some changes on the PyPI side; I'll do that when I have some time. Not sure if @cooperlees has the requisite permissions.

[webknjaz]

Please avoid building in the same job as publishing. Especially with the elevated OIDC privileges. The transitive build deps shouldn't have such level of access.

#4589 links to proper examples.

[cooperlees]

Good call - but should we do that in a dedicated PR? We already have this setup today ...

[woodruffw]

Yeah, I think there's potentially a larger CI/CD cleanup PR (or PRs) that could be done here. I can help chip away at that with some PRs 🙂

[woodruffw]

Noting for the curious: the environment itself doesn't grant any special permissions to this job -- what it does is define an environment on GitHub's side, which can then be used to further constrain the publishing workflow (e.g. by adding required manual signoffs whenever the release workflow is triggered).

The PyPI documentation has some details on that: https://docs.pypi.org/trusted-publishers/security-model/#provider-specific-considerations

[cooperlees]

Turns out I had access - So I added as prompted, but it seems it has to be the .yml file name of the workflow ...

Is this ready to be merged now if I resolve conflicts?

[woodruffw]

So I added as prompted, but it seems it has to be the .yml file name of the workflow ...
Is this ready to be merged now if I resolve conflicts?

Yep, it should be the filename of the workflow that performs the publishing operation 🙂

[cobaltt7]

I didn't add a new blank changelog after releasing 25.12 because the next release is 26.1, which is WIP in #4892. Ideally we want to keep that mostly just formatting changes, and to be conservative when considering other PRs.
However, this should be fine since it doesn't actually change Black itself, the new changelog just needs to be added still (python scripts/release.py -a)