feat(publish): allow manual workflow_dispatch for MCP Registry publish#1586
Merged
yury-s merged 1 commit intomicrosoft:mainfrom May 1, 2026
Merged
feat(publish): allow manual workflow_dispatch for MCP Registry publish#1586yury-s merged 1 commit intomicrosoft:mainfrom
yury-s merged 1 commit intomicrosoft:mainfrom
Conversation
- Expand the gate on publish-mcp-release-registry so the job also runs on workflow_dispatch (with publish-mcp-release-npm skipped). This lets us retroactively publish a previously-released version to the registry from the Actions tab without re-running npm publish. - Bump server.json from 0.0.71 to 0.0.72 to match the current package.json. Fixes the validation gap that would have failed the next release.
yury-s
added a commit
that referenced
this pull request
May 1, 2026
## Summary The first dispatch run after #1586 ([failed run](https://github.com/microsoft/playwright-mcp/actions/runs/25195774292/job/73875880165)) hit: > registry validation failed for package 1 (public/playwright/mcp): OCI packages must not have 'registryBaseUrl' field - use canonical reference in 'identifier' instead The schema permits `registryBaseUrl`, but the registry's runtime validator rejects it for OCI. The npm entry validated cleanly. ## Fix Drop the OCI package entry from `server.json`. The npm listing alone resolves #1477 (VS Code + Copilot in `registryOnly` mode installs via npx). Docker users still pull directly from `playwright.azurecr.io` — that channel doesn't need the registry to be discoverable. ## Why not reformat the OCI identifier The canonical-reference form (`registry/repo:tag`) bakes the version into the string, which means each release has to bump both `version` and the tag inside `identifier`. The version-validation step in CI would also need OCI-specific logic. Manageable but extra plumbing for a channel we don't need to list. Can be added back in a focused PR if it's ever needed. ## Verifying After merge, manually fire the `Publish` workflow against `main` from the Actions tab to publish v0.0.72 retroactively.
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.
Summary
publish-mcp-release-registryso it also runs onworkflow_dispatch. Lets us retroactively publish a previously-released version (or rerun a failed publish) from the Actions tab without re-running the npm release.server.jsonto0.0.72to matchpackage.json. The validation step added in feat(publish): publish to the official MCP Registry on release #1585 would otherwise fail the next release, sincemark v0.0.72(chore: mark v0.0.72 #1584) landed before feat(publish): publish to the official MCP Registry on release #1585 —server.jsonwas committed at0.0.71.Mechanics
The job still
needs: publish-mcp-release-npmso on a realreleaseevent it correctly waits for npm to publish first. Onworkflow_dispatch, the npm job is skipped (its ownifisrelease-only), andif: always() && needs.*.result != 'failure'/'cancelled'lets the registry job run anyway.Follow-up
Once merged, this enables a manual one-shot of v0.0.72 to the registry via the Actions tab.
Follow-up to #1585.
Reference #1477