Use trusted publishing for PyPI releases

[jyundt]

Summary

• build release distributions from the tag of a published GitHub release
• verify that the tag matches setup.py, redfish.__version__, and the changelog
• separate the unprivileged build job from the PyPI publishing job
• replace the long-lived PyPI API token with OIDC Trusted Publishing
• enable PyPI attestations and pin all third-party actions to immutable commits
• document the revised maintainer release process

Motivation

The current workflow updates and pushes release sources during a manually dispatched job, then builds and publishes with a stored PYPI_API_TOKEN. Although the work is visible in GitHub Actions, that process does not produce PyPI provenance attestations and makes it harder for downstream projects to verify the relationship between reviewed source, the release tag, and the published distributions.

This change makes the reviewed and tagged source the release input. Publishing a GitHub release starts a clean build from that tag, transfers only the resulting distributions to a dedicated publishing job, and authenticates to PyPI with a short-lived OIDC credential. The PyPI action generates attestations for the uploaded files.

This was prompted by the dependency-transparency review for the downstream Home Assistant Redfish integration.

Maintainer setup required

Before the first release using this workflow:

1. Create or configure the pypi environment in this GitHub repository. Environment protection or required reviewers can be added if desired.
2. On the PyPI redfish project, add a GitHub Trusted Publisher with:
   • owner: DMTF
   • repository: python-redfish-library
   • workflow: main.yml
   • environment: pypi
3. After the first trusted publication succeeds, remove the now-unused PYPI_API_TOKEN repository secret.

This draft should not be merged until the maintainers responsible for PyPI confirm that the Trusted Publisher can be configured.

Validation

• actionlint .github/workflows/main.yml: passed
• zizmor .github/workflows/main.yml: no findings
• release metadata validation against tag 3.3.9: passed
• source distribution and wheel build: passed
• twine check for both distributions: passed
• Python 3.14 tests: 63 tests and 35 subtests passed

The existing tox -e pep8 target continues to report pre-existing formatting errors in files untouched by this change.

[mraineri]

Could we keep this its own workflow (thus preserving the removed portions in the Release and Publish flow). I like the ease of having a push-button approach to updating versions/changelogs.

[PeterKchen2]

@mraineri It seems the current hesitation stems from a reluctance to lose the convenience of the original "push-button" automation for managing versions and changelogs. However, GitHub Actions can actually deliver the best of both worlds—preserving that ease of use while fully complying with PyPI's strict OIDC security requirements.

We can split this into a seamless two-step automated workflow:

• Step 1: Automated PR Generation (The "Push-Button" Phase)
  The maintainer triggers a workflow via workflow_dispatch (manually). This job automatically calculates the next version number, updates CHANGELOG.md/setup.py, and automatically opens a new Pull Request with those changes.
• Step 2: Secure OIDC Publishing (The "Trusted" Phase)
  Once the maintainer reviews and merges that PR, creating a GitHub Release will trigger the second, privileged workflow. This job uses the temporary GitHub OIDC token to securely publish to PyPI and upload the required provenance attestations.

By separating the repository automation from the secure publication phase, we can maintain the exact single-button convenience the maintainers prefer, while granting Home Assistant the publicly verifiable supply chain transparency it requires.

What do you think about this approach?
ainers prefer, while granting Home Assistant the publicly verifiable supply chain transparency it requires.