Use PR-specific version for dogfood VS Code extension#15892
Open
adamint wants to merge 4 commits intomicrosoft:mainfrom
Open
Use PR-specific version for dogfood VS Code extension#15892adamint wants to merge 4 commits intomicrosoft:mainfrom
adamint wants to merge 4 commits intomicrosoft:mainfrom
Conversation
For PR builds, set the extension VSIX version to 0.0.<PR_NUMBER> so dogfooded extensions are clearly distinguishable from marketplace releases. The version override flows from ci.yml through tests.yml to the vsce package command. Also support ExtensionVersionOverride MSBuild property in Extension.proj for local builds (e.g. dotnet build /p:ExtensionVersionOverride=0.0.99). Fixes microsoft#15589
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 15892Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 15892" |
vsce interprets --version as 'print tool version'. The package version must be passed as a positional argument: vsce package <version>.
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the VS Code extension build/packaging pipeline so PR dogfood builds can use a PR-specific extension version (intended as 0.0.<PR_NUMBER>) instead of the Marketplace package.json version, making dogfooded builds distinguishable.
Changes:
- Add an
EXTENSION_VERSION_OVERRIDEoutput inci.ymlfor PR runs and pass it into the reusabletests.ymlworkflow. - Add a
extensionVersionOverrideinput totests.ymland thread it into the VSIX packaging command. - Add an
ExtensionVersionOverrideMSBuild property toextension/Extension.projto influence VSIX artifact naming and intended packaging behavior.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
.github/workflows/ci.yml |
Computes and forwards an extension version override for PR builds. |
.github/workflows/tests.yml |
Accepts the override input and attempts to pass it to vsce package during VSIX creation. |
extension/Extension.proj |
Adds an override property intended to affect the packaged VSIX version and output artifact naming. |
vsce package does not have a --version flag for setting the package version (--version prints the tool version). The [version] positional arg triggers npm version bump semantics, not an explicit version set. Instead, use 'npm version --no-git-tag-version' in CI and 'node -e' in Extension.proj to update package.json before packaging.
sebastienros
reviewed
Apr 4, 2026
sebastienros
reviewed
Apr 4, 2026
JamesNK
reviewed
Apr 5, 2026
Member
JamesNK
left a comment
JamesNK
left a comment
There was a problem hiding this comment.
Two low-severity hardening suggestions around input interpolation in shell/JS contexts. The core logic looks correct.
radical
reviewed
Apr 7, 2026
…use npm version - Use 99.0.<PR> instead of 0.0.<PR> so dogfood builds rank above stable releases (sebastienros) - Use env var for inputs interpolation in tests.yml run block (JamesNK) - Replace node -e one-liner with npm version for consistency and to avoid injection (radical, JamesNK) - Save/restore package.json so override builds don't leave a dirty tree (sebastienros) - Skip node -p version extraction when ExtensionVersionOverride is set (radical) - Keep Extension.proj override path for local builds and AzDO parity
Member
|
/create-issue |
This comment was marked as off-topic.
This comment was marked as off-topic.
Member
Author
what is this? |
maddymontaquila
approved these changes
Apr 8, 2026
Member
It is a new workflow that is not ready yet. It will be used to create issues from test failures on PRs. |
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.
Description
When installing the VS Code extension from a PR dogfood build, the version is always the same as the marketplace release (currently
1.0.7frompackage.json), making it impossible to distinguish a dogfooded extension from a released one.This PR sets the extension VSIX version to
0.0.<PR_NUMBER>for PR builds, so dogfooded extensions are clearly distinguishable from marketplace releases. The version0.0.Xwas chosen because:0.0.Xis obviously non-release (major=minor=0)Changes
ci.yml: ComputeEXTENSION_VERSION_OVERRIDE=0.0.<PR_NUMBER>alongside the existingVERSION_SUFFIX_OVERRIDEand pass it totests.ymltests.yml: AcceptextensionVersionOverrideinput and pass--versiontovsce packagewhen setExtension.proj: SupportExtensionVersionOverrideMSBuild property for local builds (dotnet build Extension.proj /p:ExtensionVersionOverride=0.0.99)Non-PR builds (push to main/release) continue using the version from
package.json.Fixes #15589
Checklist