[binaryaaron]

Summary

• trigger the full release path when a v* tag is pushed
• retain manual workflow_dispatch with dry-run and create-gh-release, without a separate release-ref
• build, publish, and deploy docs from the run's triggering revision
• remove the temporary release-target checkout and project-directory task arguments added in build: migrate developer tasks to mise #211
• keep release orchestration thin by calling build:wheel, docs:build, and docs:deploy
• target manually created GitHub release tags at the triggering github.sha
• reject tag-triggered releases when the tag and built package version differ
• add regression coverage for trigger, checkout, task, and tag-release contracts

Context

This is stacked on #211. The separate release-ref came from the generic FW-CI release template in #54 and remained when #93 moved the release workflow into this repository. Safe Synthesizer later moved to tag-push releases in Safe-Synthesizer #361. This follow-up adopts that single-revision strategy while preserving manual dispatch for dry runs and controlled release testing.

Validation

• mise tasks validate: all 26 tasks passed
• mise run test -- tests/tools/test_mise_configuration.py -q: 22 focused workflow and tooling tests passed
• mise run check ::: test: 1,213 tests passed; format, lint, type, lock, SPDX, and benchmark shell checks passed
• mise run docs:build: strict documentation build passed
• independent reviewed-engineering review: accepted with no findings

Commits 5f3cb9c and 734d776 are signed and DCO-signed.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable issues remain.

Summary

This PR makes v* tag pushes run the full release path. Wheel builds, publishing, GitHub releases, and docs now use the triggering revision.

• Pushing a version tag starts a release from the tagged revision.
• Build and docs tasks now use the current checkout.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A["v* tag push or manual run"] --> B["Check out triggering revision"]
  B --> C["Build wheel"]
  C --> D{"Tag matches wheel version?"}
  D -->|Mismatch| E["Stop before uploads"]
  D -->|Match or branch run| F["Upload to Test PyPI"]
  F --> G["Upload to PyPI unless dry-run"]
  G --> H["Create GitHub release when enabled"]
  H --> I["Build and deploy release docs"]

Loading

_{Reviews (6) · Last reviewed commit: "fix(release): reject mismatched version ..." · Reviewed by Greptile}

[andreatnvidia]

Could we document the new release sequence here? Pushing a v* tag now publishes to production PyPI, creates the GitHub release, and deploys docs. It would help to explain how maintainers should use the manual dry-run before pushing the release tag, since that push starts publishing immediately.

[binaryaaron]

You are right, and this was missed: #249 merged into #211 (head 6e7a216e) with DEVELOPMENT.md still saying only that release.yml handles publishing. The Releases section in #211 now documents the sequence (commit 5ebd2f1): a pushed v* tag builds the wheel, checks the tag against the package version, publishes to Test PyPI, then PyPI, creates the GitHub release, and deploys docs. Test PyPI runs first, so a failure there stops the run before PyPI.

Checking the dry run turned up two limits that the section states plainly:

• There is no rehearsal before the tag exists. The version comes from Git tags (uv-dynamic-versioning), so an untagged commit builds a +<hash> version that PyPI and Test PyPI do not accept, and creating the tag starts the real release. The manual dry run works only on an existing release tag.
• create-gh-release defaults to true and is not gated on dry-run, so a dry run left at the default still creates the GitHub release and deploys docs.

I did not change the workflow. If you want a rehearsal that works before tagging, that needs a version override for dry runs in build:wheel; tell me if you want it in this PR or a follow-up.