A publish job that cannot succeed is not a gate, it is noise

[Shashankss1205]

The defect

Every v* tag triggers release.yml, whose publish job attempts PyPI Trusted Publishing. That OIDC exchange has never been configured on the PyPI side, so the job fails closed on every tagged release — v0.1.3 and v0.1.4 both wear a red X while the releases themselves went out by hand via twine, successfully. A job that is known in advance to fail teaches people to ignore red, which is the one thing a CI signal must never do.

The fix

The publish job is now additionally gated on a repository variable:

if: startsWith(github.ref, 'refs/tags/') && vars.PYPI_TRUSTED_PUBLISHING == 'true'

Until the variable exists, a tag still runs the full build-and-verify job (tag-matches-version check, twine metadata check, wheel-installs-and-imports-everything check, sdist leak check) and the run finishes green with publish skipped — the gate keeps gating, the noise stops.

When the one-time PyPI configuration is done (this repo, this workflow filename, the pypi environment), flip PYPI_TRUSTED_PUBLISHING to true under Settings → Secrets and variables → Actions → Variables, and tags publish themselves. Fail-closed is preserved in the wrong-order case: flipping the variable without the PyPI-side setup still fails on the OIDC exchange rather than uploading anything.

The workflow header and the job comment both document the variable and the flip, so the next person reading a skipped publish job knows exactly why it skipped and what makes it run.

No behavior change for workflow_dispatch dry runs. YAML validated; packaging tests green.

🤖 Generated with Claude Code

[Shashankss1205]

The defect

Every v* tag triggers release.yml, whose publish job attempts PyPI Trusted Publishing. That OIDC exchange has never been configured on the PyPI side, so the job fails closed on every tagged release — v0.1.3 and v0.1.4 both wear a red X while the releases themselves went out by hand via twine, successfully. A job that is known in advance to fail teaches people to ignore red, which is the one thing a CI signal must never do.

The fix

The publish job is now additionally gated on a repository variable:

if: startsWith(github.ref, 'refs/tags/') && vars.PYPI_TRUSTED_PUBLISHING == 'true'

Until the variable exists, a tag still runs the full build-and-verify job (tag-matches-version check, twine metadata check, wheel-installs-and-imports-everything check, sdist leak check) and the run finishes green with publish skipped — the gate keeps gating, the noise stops.

When the one-time PyPI configuration is done (this repo, this workflow filename, the pypi environment), flip PYPI_TRUSTED_PUBLISHING to true under Settings → Secrets and variables → Actions → Variables, and tags publish themselves. Fail-closed is preserved in the wrong-order case: flipping the variable without the PyPI-side setup still fails on the OIDC exchange rather than uploading anything.

The workflow header and the job comment both document the variable and the flip, so the next person reading a skipped publish job knows exactly why it skipped and what makes it run.

No behavior change for workflow_dispatch dry runs. YAML validated; packaging tests green.

🤖 Generated with Claude Code

[Shashankss1205]

The defect

Every v* tag triggers release.yml, whose publish job attempts PyPI Trusted Publishing. That OIDC exchange has never been configured on the PyPI side, so the job fails closed on every tagged release — v0.1.3 and v0.1.4 both wear a red X while the releases themselves went out by hand via twine, successfully. A job that is known in advance to fail teaches people to ignore red, which is the one thing a CI signal must never do.

The fix

The publish job is now additionally gated on a repository variable:

if: startsWith(github.ref, 'refs/tags/') && vars.PYPI_TRUSTED_PUBLISHING == 'true'

Until the variable exists, a tag still runs the full build-and-verify job (tag-matches-version check, twine metadata check, wheel-installs-and-imports-everything check, sdist leak check) and the run finishes green with publish skipped — the gate keeps gating, the noise stops.

When the one-time PyPI configuration is done (this repo, this workflow filename, the pypi environment), flip PYPI_TRUSTED_PUBLISHING to true under Settings → Secrets and variables → Actions → Variables, and tags publish themselves. Fail-closed is preserved in the wrong-order case: flipping the variable without the PyPI-side setup still fails on the OIDC exchange rather than uploading anything.

The workflow header and the job comment both document the variable and the flip, so the next person reading a skipped publish job knows exactly why it skipped and what makes it run.

No behavior change for workflow_dispatch dry runs. YAML validated; packaging tests green.

🤖 Generated with Claude Code

[Shashankss1205]

The defect

Every v* tag triggers release.yml, whose publish job attempts PyPI Trusted Publishing. That OIDC exchange has never been configured on the PyPI side, so the job fails closed on every tagged release — v0.1.3 and v0.1.4 both wear a red X while the releases themselves went out by hand via twine, successfully. A job that is known in advance to fail teaches people to ignore red, which is the one thing a CI signal must never do.

The fix

The publish job is now additionally gated on a repository variable:

if: startsWith(github.ref, 'refs/tags/') && vars.PYPI_TRUSTED_PUBLISHING == 'true'

Until the variable exists, a tag still runs the full build-and-verify job (tag-matches-version check, twine metadata check, wheel-installs-and-imports-everything check, sdist leak check) and the run finishes green with publish skipped — the gate keeps gating, the noise stops.

When the one-time PyPI configuration is done (this repo, this workflow filename, the pypi environment), flip PYPI_TRUSTED_PUBLISHING to true under Settings → Secrets and variables → Actions → Variables, and tags publish themselves. Fail-closed is preserved in the wrong-order case: flipping the variable without the PyPI-side setup still fails on the OIDC exchange rather than uploading anything.

The workflow header and the job comment both document the variable and the flip, so the next person reading a skipped publish job knows exactly why it skipped and what makes it run.

No behavior change for workflow_dispatch dry runs. YAML validated; packaging tests green.

🤖 Generated with Claude Code

[Shashankss1205]

The defect

Every v* tag triggers release.yml, whose publish job attempts PyPI Trusted Publishing. That OIDC exchange has never been configured on the PyPI side, so the job fails closed on every tagged release — v0.1.3 and v0.1.4 both wear a red X while the releases themselves went out by hand via twine, successfully. A job that is known in advance to fail teaches people to ignore red, which is the one thing a CI signal must never do.

The fix

The publish job is now additionally gated on a repository variable:

if: startsWith(github.ref, 'refs/tags/') && vars.PYPI_TRUSTED_PUBLISHING == 'true'

Until the variable exists, a tag still runs the full build-and-verify job (tag-matches-version check, twine metadata check, wheel-installs-and-imports-everything check, sdist leak check) and the run finishes green with publish skipped — the gate keeps gating, the noise stops.

When the one-time PyPI configuration is done (this repo, this workflow filename, the pypi environment), flip PYPI_TRUSTED_PUBLISHING to true under Settings → Secrets and variables → Actions → Variables, and tags publish themselves. Fail-closed is preserved in the wrong-order case: flipping the variable without the PyPI-side setup still fails on the OIDC exchange rather than uploading anything.

The workflow header and the job comment both document the variable and the flip, so the next person reading a skipped publish job knows exactly why it skipped and what makes it run.

No behavior change for workflow_dispatch dry runs. YAML validated; packaging tests green.

🤖 Generated with Claude Code

[Shashankss1205]

The defect

Every v* tag triggers release.yml, whose publish job attempts PyPI Trusted Publishing. That OIDC exchange has never been configured on the PyPI side, so the job fails closed on every tagged release — v0.1.3 and v0.1.4 both wear a red X while the releases themselves went out by hand via twine, successfully. A job that is known in advance to fail teaches people to ignore red, which is the one thing a CI signal must never do.

The fix

The publish job is now additionally gated on a repository variable:

if: startsWith(github.ref, 'refs/tags/') && vars.PYPI_TRUSTED_PUBLISHING == 'true'

Until the variable exists, a tag still runs the full build-and-verify job (tag-matches-version check, twine metadata check, wheel-installs-and-imports-everything check, sdist leak check) and the run finishes green with publish skipped — the gate keeps gating, the noise stops.

When the one-time PyPI configuration is done (this repo, this workflow filename, the pypi environment), flip PYPI_TRUSTED_PUBLISHING to true under Settings → Secrets and variables → Actions → Variables, and tags publish themselves. Fail-closed is preserved in the wrong-order case: flipping the variable without the PyPI-side setup still fails on the OIDC exchange rather than uploading anything.

The workflow header and the job comment both document the variable and the flip, so the next person reading a skipped publish job knows exactly why it skipped and what makes it run.

No behavior change for workflow_dispatch dry runs. YAML validated; packaging tests green.

🤖 Generated with Claude Code

[Shashankss1205]

The defect

Every v* tag triggers release.yml, whose publish job attempts PyPI Trusted Publishing. That OIDC exchange has never been configured on the PyPI side, so the job fails closed on every tagged release — v0.1.3 and v0.1.4 both wear a red X while the releases themselves went out by hand via twine, successfully. A job that is known in advance to fail teaches people to ignore red, which is the one thing a CI signal must never do.

The fix

The publish job is now additionally gated on a repository variable:

if: startsWith(github.ref, 'refs/tags/') && vars.PYPI_TRUSTED_PUBLISHING == 'true'

Until the variable exists, a tag still runs the full build-and-verify job (tag-matches-version check, twine metadata check, wheel-installs-and-imports-everything check, sdist leak check) and the run finishes green with publish skipped — the gate keeps gating, the noise stops.

When the one-time PyPI configuration is done (this repo, this workflow filename, the pypi environment), flip PYPI_TRUSTED_PUBLISHING to true under Settings → Secrets and variables → Actions → Variables, and tags publish themselves. Fail-closed is preserved in the wrong-order case: flipping the variable without the PyPI-side setup still fails on the OIDC exchange rather than uploading anything.

The workflow header and the job comment both document the variable and the flip, so the next person reading a skipped publish job knows exactly why it skipped and what makes it run.

No behavior change for workflow_dispatch dry runs. YAML validated; packaging tests green.

🤖 Generated with Claude Code

[Shashankss1205]

The defect

Every v* tag triggers release.yml, whose publish job attempts PyPI Trusted Publishing. That OIDC exchange has never been configured on the PyPI side, so the job fails closed on every tagged release — v0.1.3 and v0.1.4 both wear a red X while the releases themselves went out by hand via twine, successfully. A job that is known in advance to fail teaches people to ignore red, which is the one thing a CI signal must never do.

The fix

The publish job is now additionally gated on a repository variable:

if: startsWith(github.ref, 'refs/tags/') && vars.PYPI_TRUSTED_PUBLISHING == 'true'

Until the variable exists, a tag still runs the full build-and-verify job (tag-matches-version check, twine metadata check, wheel-installs-and-imports-everything check, sdist leak check) and the run finishes green with publish skipped — the gate keeps gating, the noise stops.

When the one-time PyPI configuration is done (this repo, this workflow filename, the pypi environment), flip PYPI_TRUSTED_PUBLISHING to true under Settings → Secrets and variables → Actions → Variables, and tags publish themselves. Fail-closed is preserved in the wrong-order case: flipping the variable without the PyPI-side setup still fails on the OIDC exchange rather than uploading anything.

The workflow header and the job comment both document the variable and the flip, so the next person reading a skipped publish job knows exactly why it skipped and what makes it run.

No behavior change for workflow_dispatch dry runs. YAML validated; packaging tests green.

🤖 Generated with Claude Code