From 7542597e17ae4a9c38d404ff16d0b2aaa494b224 Mon Sep 17 00:00:00 2001 From: "V. David Zvenyach" Date: Tue, 4 Aug 2026 07:21:12 -0400 Subject: [PATCH] ci(publish): make the PyPI upload idempotent so a Release cannot go red over a duplicate MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `uv publish` fails the run when a file is already on the index, so any version that reached PyPI by another route — a manual `uv publish`, a re-run of this workflow, a partial upload — makes the GitHub Release that triggers it go red even though the package is fine and nothing needs doing. That is exactly what happened with 1.5.0: it was published by hand before the Release existed, which left cutting the Release as a choice between skipping it (losing the tag and notes every prior version has) and accepting a failed run attached to it. `--check-url` has uv query the index first and skip files already present, so the step is a no-op instead of an error. Re-running the workflow is now always safe. Co-Authored-By: Claude Opus 5 (1M context) --- .github/workflows/publish.yml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/.github/workflows/publish.yml b/.github/workflows/publish.yml index 5c7e6d4..1b92781 100644 --- a/.github/workflows/publish.yml +++ b/.github/workflows/publish.yml @@ -26,4 +26,8 @@ jobs: - name: Publish to PyPI env: UV_PUBLISH_TOKEN: ${{ secrets.TANGO_PYPI_TOKEN }} - run: uv publish + # --check-url makes the upload idempotent: uv queries the index first and skips + # files already present instead of failing the run. Without it, any version that + # reached PyPI by another route — a manual `uv publish`, a re-run of this + # workflow — makes the GitHub Release that follows it go red for no real reason. + run: uv publish --check-url https://pypi.org/simple/