Make the PyPI publish job opt-in - #6
Merged
Merged
Conversation
flypad is not on PyPI and there is no trusted publisher configured, so as it stood every tag would build and smoke-test cleanly and then fail red on a publish step that could never have worked. A red job on every release is noise that trains you to ignore release runs. The job is now gated on a repository variable, PYPI_PUBLISH. Unset, the job is skipped — grey, which is the honest signal for "not enabled" rather than "broken". Enabling it later needs no workflow edit: register the trusted publisher on PyPI, create the `pypi` environment, set the variable to "true". Verified the variable is currently unset, so v0.2.0 will tag green with build and smoke running and publish skipped.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Makes the PyPI
publishjob opt-in, so tagging v0.2.0 produces a green release runinstead of a red one.
Why
flypad is not on PyPI and no trusted publisher is configured for this repository. As the
workflow stood, every tag would build the distributions, smoke-test the wheel — both fine —
and then fail on a
publishstep that could never have succeeded. A release run that isalways red is worse than no signal at all: it trains you to ignore the one workflow whose
failures matter most.
Worth noting the job could not have worked even with a publisher configured until the
previous PR:
uv buildwas producing a 124 MB sdist, over PyPI's 100 MB per-file limit.That is fixed on
main; this PR handles the remaining half.What changes
One condition on the
publishjob:Unset, the job is skipped — grey, which is the honest signal for "not enabled", as
opposed to red for "broken".
buildandsmokestill run on every tag, so the release isstill verified end-to-end; only the upload is withheld.
Enabling PyPI later needs no workflow edit:
release.yml,environment
pypi);pypienvironment under Settings → Environments;PYPI_PUBLISHtotrueunderSettings → Secrets and variables → Actions → Variables.
Those steps are recorded in the job's comment so they are there when they are wanted,
along with the reminder that publishing is irreversible — a version, once accepted by PyPI,
cannot be reused.
Verification
gh variable listreports no repository variables, so the gate currently evaluates falseand the job will skip. Tagging v0.2.0 after this merges should give
build✅,smoke✅,publish⏭️.Nothing else in the workflow changes, and
release.ymlonly triggers onv*tags, so thiscannot affect
ciordocs.Order
This needs to be on
mainbefore thev0.2.0tag is created — a tag created firstwould still carry the ungated job and fail red on the run.