Add independent VS Code extension releases - #64139
Add independent VS Code extension releases#64139Jake Bailey (jakebailey) wants to merge 24 commits into
Conversation
Validate the package-lock version before creating a release tag and remove the unsupported test-signing path from the VSIX build pipeline.
There was a problem hiding this comment.
🟡 Changes recommended
The bump workflow must branch from main and create the documented pull request.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Adds independent versioning, tagging, building, signing, and publishing for the VS Code TypeScript extension.
Changes:
- Adds version-bump and release-tag workflows.
- Adds dedicated Azure build and publish pipelines.
- Extends packaging with independent versions and release manifests.
File summaries
| File | Description |
|---|---|
tools/pipelines/vscode-typescript-publish.yml |
Validates and publishes release artifacts. |
tools/pipelines/vscode-typescript-build.yml |
Builds and signs tagged VSIX artifacts. |
Herebyfile.mjs |
Implements extension release packaging and manifests. |
.github/workflows/tag-vscode-typescript.yml |
Creates reviewed release tags. |
.github/workflows/bump-vscode-typescript.yml |
Prepares version-bump release branches. |
Review details
- Files reviewed: 5/5 changed files
- Comments generated: 2
- Review effort level: Balanced
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
There was a problem hiding this comment.
🟡 Changes recommended
The release supply chain is not lockfile-pinned, and release-mode CI coverage and PR-trigger safeguards are missing.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
- Files reviewed: 10/11 changed files
- Comments generated: 3
- Review effort level: Balanced
Fetch native package tarballs using the lockfile URLs and verify their\nSHA-512 integrity before packaging. Exercise the extension release path in\nCI and explicitly disable pull request triggers for the publish pipeline.
There was a problem hiding this comment.
🔵 Needs a closer look
Release asset consistency remains unresolved, and the publishing workflow requires final human review.
Review details
Suppressed comments (1)
tools/pipelines/vscode-typescript-publish.yml:246
- This note attributes the bundled compiler to the extension release commit, but the compiler is downloaded from the pinned
@typescript/bundled-typescriptnpm package and may have been built from a different commit. Label this SHA as the extension source commit so the release metadata does not imply incorrect compiler provenance.
--notes "Bundles TypeScript $bundledTypeScriptVersion from commit $sourceCommit."
- Files reviewed: 10/11 changed files
- Comments generated: 1
- Review effort level: Balanced
There was a problem hiding this comment.
🟡 Changes recommended
Tag validation must reject leading-zero SemVer components before creating permanent release tags.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
- Files reviewed: 10/11 changed files
- Comments generated: 1
- Review effort level: Balanced
| exit 0 | ||
| fi | ||
|
|
||
| if ! [[ "$version" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then |
This adds the release workflow for our VS Code extension.
The release procedure is:
vscode-typescript/v1.2.3Perhaps a bit roundabout, and requires two manual steps, but we could not require a second approval to actually get the bits out.
I expect to do something somewhat similar for the main TS releases, which have to operate in a very similar way.
Fixes #63924