fix(release): publish the MCP registry entry after the release is public - #1584
Merged
Conversation
v0.10.3 published, then failed:
MCPB package '...codebase-memory-mcp-darwin-amd64.mcpb' is not publicly
accessible (status: 404)
publish-mcp-registry and publish-final both needed only publish-registries, so
they ran in PARALLEL — and publish-final is the job that un-drafts the release.
The registry validates every package URL it is handed by fetching it, and a
draft release's assets are not publicly readable. The registry lost the race by
five seconds; the identical URL served 200 once the release went public, and the
job passed on a plain re-run.
The registry now needs publish-final. This keeps the documented intent exactly:
publish-final still does NOT depend on the registry, so a registry-preview
outage can never block shipping — the registry simply runs after the assets it
validates exist to the outside world.
The gate-chain contract now pins BOTH directions, because either one alone is a
bug: the registry must depend on publish-final, and publish-final must never
depend on the registry. Verified by reverting the ordering — the contract goes
red with the exact v0.10.3 failure, and green again with it restored.
This is the second latent defect the .mcpb path produced on its first real
release (after the security-strings audit treating a manifest as a binary).
Both were invisible until a stable release ran; an end-to-end bundle gate is
worth adding before the next one.
Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.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
1 participant
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.
v0.10.3 published and then failed its registry step:
publish-mcp-registryandpublish-finalboth needed onlypublish-registries, so they ran in parallel — andpublish-finalis the job that un-drafts the release. The registry validates every package URL it is handed by fetching it, and a draft release's assets are not publicly readable. It lost the race by five seconds; the same URL served 200 once the release went public, and the job passed on a plain re-run.Fix: the registry now
needs: [publish-registries, publish-final]. This preserves the documented intent exactly —publish-finalstill does not depend on the registry, so a registry outage can never block shipping. The registry just runs after the assets it validates actually exist publicly.Contract:
test_release_gate_chain_contract.shnow pins both directions, since either alone is a bug — the registry must depend on publish-final, and publish-final must never depend on the registry. Revert-checked: reverting the ordering reproduces the exact v0.10.3 failure as a red contract.Note this is the second latent defect the
.mcpbpath produced on its first real release (after the security-strings audit treating a manifest as a compiled binary). Both were invisible until a stable release ran — an end-to-end bundle gate is worth adding before the next one.