Repository navigation
AB#3142 Release: gate the PyPI publish on the exe verification - #4
Merged
Merged
Conversation
publish-pypi depended on `build` alone. build-windows-exe - which packs the single-file exe and asserts it answers an MCP initialize handshake - has no artifact the publish consumes, so it ran in PARALLEL with the publish rather than before it. A PyInstaller or packaging break would have been reported by a red job while the release was already on PyPI. That asymmetry matters because publishing is the only irreversible step in this workflow: a PyPI version number can never be reused, so a bad publish costs a version and a follow-up release, whereas a bad tag is just `git tag -d`. publish-pypi now needs [build, build-windows-exe]. The graph stays a DAG and github-release still runs last; the cost is a few minutes of Windows-runner time before the publish, which is the right trade for an action that cannot be undone. Found while releasing v0.0.31: the mcp 2.0 migration swapped the SDK underneath a frozen binary, so the exe was packed and smoke-tested locally before tagging to compensate for exactly this gap. That manual step is no longer load-bearing. Verified by parsing release.yml and asserting the job graph: deps all resolve, no cycles, publish-pypi gated on both build and build-windows-exe, trigger unchanged (push on v* tags). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
2 participants
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.
publish-pypidepended onbuildalone.build-windows-exe— which packs the single-file exe and asserts it answers an MCPinitializehandshake — produces no artifact the publish consumes, so it ran in parallel with the publish rather than before it. A PyInstaller or packaging break would have been reported by a red job while the release was already on PyPI.That asymmetry matters because publishing is the only irreversible step here: a PyPI version number can never be reused. A bad publish costs a version and a follow-up release; a bad tag is just
git tag -d.Change
Job graph after
buildbuild-windows-exepublish-pypibuild,build-windows-exegithub-releasepublish-pypi,build-windows-exeThe two build jobs still run concurrently; only the irreversible step waits. Verified by parsing
release.ymland asserting the graph: all deps resolve, no cycles,publish-pypigated on both,github-releasestill last, trigger unchanged (pushonv*).Why now
Found while releasing v0.0.31. The mcp 2.0 migration swapped the SDK underneath a frozen binary — new module tree, new transitive deps — which is exactly the shape of change that breaks PyInstaller. I packed the exe and ran the smoke test locally before tagging to compensate. That manual step is no longer load-bearing.
Note
release.ymlonly triggers onv*tags, so merging this does not exercise it. The next tag will be the first real run; the graph assertions above are the pre-merge evidence.