From 0170cbc52cb07a4deb0bfeb5a7c7c03d38c8a311 Mon Sep 17 00:00:00 2001 From: Ben Hearsum Date: Tue, 9 Jun 2026 14:58:39 -0400 Subject: [PATCH] repin pypi-publish action Quoting context from @ahal in #981: > Outlined my rationale in channel, copy/pasting here: > > I think I understand.. The release/v1 branch is like a latest tag.. it points to whatever the latest release on the 1.x branch line is: https://github.com/pypa/gh-action-pypi-publish/tree/release/v1 > > but because we're using renovate now, it'll find the tag refs directly.. so it's likely equivalent to using release/v1 but we get to update explicitly instead of implicitly --- .github/workflows/pypi-publish.yml | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/.github/workflows/pypi-publish.yml b/.github/workflows/pypi-publish.yml index addb21214..ea6264ead 100644 --- a/.github/workflows/pypi-publish.yml +++ b/.github/workflows/pypi-publish.yml @@ -21,9 +21,14 @@ jobs: run: | pip install build python -m build + # NOTE: We deliberately pin this action to a commit SHA rather than the + # mutable `@release/v1` ref that PyPA recommends. The pin stops the + # action from being swapped out from under a workflow that holds PyPI + # publish (OIDC) rights; the cost is losing automatic upstream patches. + # Renovate offsets that by bumping the pinned SHA (tracked via the + # trailing `# vX.Y.Z` comment), so merge those bump PRs promptly. - name: Publish package distributions to PyPI - # deliberately pinned to release/v1 to be allowed by our action pinning requirements - uses: pypa/gh-action-pypi-publish@release/v1 + uses: pypa/gh-action-pypi-publish@cef221092ed1bacb1cc03d23a2d87d1d172e277b # v1.14.0 pypi-publish-pytest-taskgraph: name: upload release to PyPI if: startsWith(github.ref, 'refs/tags/pytest-taskgraph')