Keep onboarding provider-neutral and automate registry releases - #5
Merged
Merged
Conversation
markmnl
changed the title
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.
Make fmsg onboarding and registry connections provider-neutral. Users supply their hosting provider's OAuth or API-key MCP endpoint, or configure the local npm package. The README removes the named hosting recommendation, explains OAuth sign-in, and covers hosts that do not support registry URL templates.
Publishing a stable GitHub release now publishes npm first, then the matching MCP Registry metadata in a separate job. Registry publishing uses GitHub OIDC with no dedicated secret and a pinned, checksum-verified publisher CLI. Both versions come from the release tag. A failed registry job can be retried without republishing npm; drafts and prereleases do not publish.
Validation: the official registry validation endpoint returned
valid: true; both manifests pass its JSON schema.actionlint, workflow shell syntax checks, README relative links andgit diff --checkpass. Local execution of the actual release steps verified version stamping, prerelease-tag rejection, preservation of the remote configuration, and publisher download/checksum/extraction. Live GitHub OIDC publishing will be exercised by the next stable release.The neutral metadata is already published and verified as latest at registry version
0.2.1-registry.1, pointing to the existing npm0.2.0package. Source version fields remain managed by the release workflow.