Repository navigation
Add new ESRP + changesets publish system - #3687
Draft
Jake Bailey (jakebailey) wants to merge 8 commits into
Draft
Jake Bailey (jakebailey) wants to merge 8 commits into
Jake Bailey (jakebailey) wants to merge 8 commits into
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Jake Bailey (jakebailey)
force-pushed
the
azdo-esrp-changesets-publish
branch
from
October 30, 2026 22:21
7e9210a to
bdd34c7
Compare
There was a problem hiding this comment.
🟡 Changes recommended
The release logic can skip unpublished versions in multi-commit pushes, and proxy opt-in is missing for token creation and revocation tasks.
2 open issues
What changed in this PR
Moves npm publishing from GitHub Actions to an Azure Pipelines ESRP release flow, while retaining Changesets for version management.
Changes:
- Adds dependency-ordered package staging and ESRP publishing.
- Adds retry-aware npm checks and GitHub tag/release creation using a Key Vault-backed GitHub App token.
- Removes direct publishing from GitHub Actions and adds a required CI check for publish-stage capacity.
| File | Description |
|---|---|
build/azure-pipelines/steps/create-github-app-token.yml |
Creates and revokes GitHub App tokens using Azure Key Vault. |
build/azure-pipelines/release.yml |
Defines build, ESRP publish, and GitHub finalization stages. |
build/azure-pipelines/release-helper.mjs |
Checks existing npm versions and creates GitHub tags and releases. |
build/azure-pipelines/pack-changed-packages.mjs |
Selects version changes and stages package archives in dependency order. |
.github/workflows/publish-packages.yml |
Removes direct npm publishing and its token environment variable. |
.github/workflows/CI.yml |
Adds required validation of release-pipeline stage capacity. |
Review effort: Balanced
Packages need to be published to npm through ESRP rather than with an npm token stored in GitHub Actions. ESRP can only be used from an Azure Pipelines release job, so changesets can no longer publish packages itself. Add a release pipeline that runs on every push to v2. Like the existing single-package release pipelines, it publishes the package versions changed by the latest commit, which for changesets is the merged "Version Packages" PR, and does nothing otherwise. Packages are published one ESRP release per level of the workspace dependency graph, so a failed release never leaves a published package depending on an unpublished version. A CI job checks that the pipeline defines enough stages for the current graph. All stages run in one job, so retrying a partially failed run would resubmit packages that already succeeded, which ESRP rejects. Before each stage, skip any versions that are already on npm.
The release pipeline now publishes packages through ESRP, so changesets/action only needs to open the "Version Packages" PR.
When changesets/action published packages itself, it also pushed a name@version tag and created a GitHub release with the changelog entry for each package. Publishing through ESRP dropped both. Recreate them from the publish manifest once publishing finishes, so a release looks the same as before. This reuses the GitHub App token template from tslib's release pipeline, since release jobs have no checkout to run the token CLI from.
Jake Bailey (jakebailey)
force-pushed
the
azdo-esrp-changesets-publish
branch
from
October 30, 2026 22:29
bdd34c7 to
03f2392
Compare
The release pipeline runs under network isolation that blocks registry.npmjs.org, and the typescriptlang-org bootstrap fetches TypeScript's dist-tags from there, so the Build stage would fail. None of the published packages depend on the site, so bootstrap everything else.
The check was meant to skip versions that an earlier attempt already published, so that rerunning a partially failed run wouldn't resubmit them. But the release job's network isolation blocks registry.npmjs.org, so the check could never succeed, and it isn't needed anyway: ESRP succeeds for versions that are already on npm. Have the build report which stages have packages instead, so the publish job no longer needs Node or the network.
Upstream's publish script ran `changeset git-tag` before publishing, and changesets/action pushed the tags it reported and created a GitHub release for each. The action can still do that without publishing, so run `changeset git-tag` as its publish script instead of recreating the same thing in the release pipeline. This replaces the Finalize stage, its helper script and the GitHub App token template. Tags and releases now appear when the "Version Packages" PR is merged rather than after ESRP finishes.
There was a problem hiding this comment.
🔵 Needs a closer look
The production publishing path depends on unavailable internal MicroBuild/ESRP templates and agent network policy, requiring an end-to-end release to validate template expansion, artifact transfer, and publishing authorization.
No open issues 🎉
2 resolved since last review
Review effort: Balanced
Changesets also patches sandbox and twoslash, which depend on vfs, so the first release exercises both publish levels.
This branch has not been deployed
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
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.
No description provided.