Skip to content

Make the release pipeline rehearsable without publishing - #3

Merged
Boernsman merged 1 commit into
mainfrom
release-rehearsal
Aug 30, 2026
Merged

Make the release pipeline rehearsable without publishing#3
Boernsman merged 1 commit into
mainfrom
release-rehearsal

Conversation

@Boernsman

@Boernsman Boernsman commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

workflow_dispatch was listed as a trigger on release.yml and could never
work: GITHUB_REF_NAME is the branch on a manual run, so the
tag-matches-version step compared a branch name to a version and failed on the
first step, every time. There was no way to exercise the release pipeline short
of pushing a tag, and a tag cannot be taken back.

What a manual run does now

Target Builds, checks, installs Uploads
rehearse (default) yes nothing
testpypi yes test.pypi.org
pypi yes PyPI

pypi has to be chosen by name, so the default manual run cannot reach PyPI by
accident. Tag pushes are unchanged: they publish to PyPI and then create the
GitHub release.

twine check

The useful addition even for real releases. It is what PyPI validates on
upload, and nothing else in the pipeline looks at the metadata or at whether
the README renders. Without it, the first sign of a bad long_description is
the upload rejecting it — after the tag exists.

The rehearsal also installs the built wheel into a clean environment and runs
it, so a green rehearsal means the artifact works, not just that it built.

Verified locally

  • twine check --strict passes on both artifacts built from this commit
  • the install-and-run step runs end to end from the built wheel: --version,
    check --strict, generate, and the generated firmware's own 68 host checks
  • the workflow parses and the job conditions resolve as intended

Still needed before a real release

The PyPI trusted publisher, which is what this makes it possible to defer:
pypi.org/manage/project/pinside/settings/publishing with owner
bitcrushtesting, repository pinside, workflow release.yml, environment
pypi. testpypi needs the same at test.pypi.org if you want to exercise the
upload path first.

workflow_dispatch was listed as a trigger and could never work.
GITHUB_REF_NAME is the branch on a manual run, so the tag-matches-version
step compared a branch name to a version and failed on the first step every
time. There was no way to exercise the release short of tagging, and a tag
cannot be taken back.

A manual run now takes a target. `rehearse`, the default, does everything a
tag does except publish: builds the sdist and wheel, asserts the wheel still
carries the firmware templates, runs twine check, installs the wheel into a
clean environment and generates firmware from it. `testpypi` additionally
uploads to test.pypi.org, for exercising the upload itself. `pypi` is there
for a manual re-run of a release that half failed, and has to be asked for
by name, so the default manual run cannot reach PyPI by accident.

twine check is the useful addition even for tagged releases: it is what PyPI
validates on upload, and nothing else in the pipeline looks at the metadata
or at whether the README renders. Without it the first sign of a bad
long_description is the upload rejecting it, at which point the tag exists.

Verified locally: twine check --strict passes on both artifacts built from
this commit, the install-and-run step runs end to end from the built wheel,
and the workflow parses with the job conditions resolving as intended.
@Boernsman
Boernsman merged commit 146ab87 into main Aug 30, 2026
9 checks passed
@Boernsman
Boernsman deleted the release-rehearsal branch August 30, 2026 17:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant