Conversation
hallipr
requested review from
alzimmermsft,
jongio,
joshfree,
msalaman,
saikoumudi,
sandeep-sen and
vukelich
There was a problem hiding this comment.
Pull request overview
This PR moves MCP registry publishing of server.json from a custom Go-based deploy script to an ESRP-based release flow in the Azure Pipelines release job, removing the Go install/build/deploy scripts from the repo.
Changes:
- Removed the PowerShell scripts that installed Go and built/ran the MCP registry publisher tool.
- Updated the release pipeline to use a dedicated
mcp-registry/release-server-json.ymljob template. - Updated the MCP registry release job to stage
server.json, publish it as a pipeline artifact, and release it viaESRPRelease@10.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| eng/scripts/Install-Go.ps1 | Deleted; no longer needed after removing Go-based publisher flow. |
| eng/scripts/Deploy-ServerJson.ps1 | Deleted; replaced by ESRP-based release mechanism. |
| eng/pipelines/templates/jobs/release.yml | Switched from the prior update job template to the new MCP registry release job template. |
| eng/pipelines/templates/jobs/mcp-registry/release-server-json.yml | Stages server.json, publishes artifact, and uses ESRPRelease@10 to publish to the MCP registry. |
Comments suppressed due to low confidence (3)
eng/pipelines/templates/jobs/mcp-registry/release-server-json.yml:66
- The staging step copies server.json into the root of
$(Build.ArtifactStagingDirectory) and ESRPRelease later publishes the entire folder. If any other files land in that directory in this job (now or in future edits), they could be unintentionally released to the MCP registry. Stage into a dedicated subfolder (e.g., $ (Build.ArtifactStagingDirectory)/serverjson) and point both the artifact publish and ESRP FolderLocation at that subfolder to ensure only server.json is released.
eng/pipelines/templates/jobs/mcp-registry/release-server-json.yml:60 - This logs the full contents of server.json to the build output. That can be very noisy, and if server.json ever contains more than public metadata (e.g., internal endpoints), it would be exposed in pipeline logs. Consider removing the dump or replacing it with a lightweight validation (e.g., file exists + JSON parse) and/or logging only the path and a few key fields.
eng/pipelines/templates/jobs/mcp-registry/release-server-json.yml:76 - The ESRPRelease task displayName still references publishing native platform packages to npmjs.com, which doesn’t match what this step does (publishes server.json to the MCP registry). Updating the displayName will make pipeline runs easier to understand and troubleshoot.
jongio
left a comment
jongio
left a comment
There was a problem hiding this comment.
Replaces the Go-based deploy tool with ESRP for publishing server.json - nice cleanup removing ~1000 lines of Go install/build/deploy scripts.
Issues to address:
- release-server-json.yml:74 - ESRP task runs in a regular
job:but every other ESRP release in this repo usesdeployment:withtemplateContext: type: releaseJob- this likely explains the CI failure - release-server-json.yml:63 - server.json staged to ArtifactStagingDirectory root rather than a subdirectory
Is it intentional that the old staging/internal publishTarget routing from Deploy-ServerJson.ps1 is dropped? The old script would skip deployment for internal builds.
| path: $(Build.ArtifactStagingDirectory) | ||
| artifact: server.json_${{ parameters.ServerName }} | ||
|
|
||
| - task: ESRPRelease@11 |
There was a problem hiding this comment.
[MEDIUM] This ESRP task runs in a regular job:, but every other ESRP release in this repo (release-npm.yml, release-pypi.yml) uses a deployment: job with templateContext: { type: releaseJob, isProduction: true } and environment: package-publish. In 1ES pipelines, ESRP service connections are typically only injected for releaseJob contexts. The CI failure on "Release Publish server.json to MCP Repository" is likely related.
Consider switching to deployment: type to match the npm/pypi pattern - this would involve adding templateContext, environment: package-publish, and wrapping steps under strategy: runOnce: deploy: steps:.
|
|
||
| $stagingDirectory = '$(Build.ArtifactStagingDirectory)' | ||
| New-Item -ItemType Directory -Path $stagingDirectory -ErrorAction SilentlyContinue | Out-Null | ||
| Copy-Item -Path $serverJsonPath -Destination $stagingDirectory |
There was a problem hiding this comment.
[LOW] Staging server.json directly to $(Build.ArtifactStagingDirectory) root. The pypi release template isolates files into a dedicated subdirectory before handing to ESRP to prevent unintended files from being released. Low risk right now since this is the only copy operation, but a subdirectory would be safer as the job evolves.
What does this PR do?
Instead of building and running the server.json deploy tool, use the ESRP release task to update the central mcp registry
Pre-merge Checklist
servers/Azure.Mcp.Server/README.mdand/orservers/Fabric.Mcp.Server/README.mddocumentationREADME.mdchanges running the script./eng/scripts/Process-PackageReadMe.ps1. See Package READMEToolDescriptionEvaluatorand obtained a score of0.4or more and a top 3 ranking for all related test promptsconsolidated-tools.jsonbreaking-changelabelservers/Azure.Mcp.Server/docs/azmcp-commands.md./eng/scripts/Update-AzCommandsMetadata.ps1to update tool metadata inazmcp-commands.md(required for CI)servers/Azure.Mcp.Server/docs/e2eTestPrompts.mdcrypto mining, spam, data exfiltration, etc.)/azp run mcp - pullrequest - liveto run Live Test Pipeline