Fix Windows VSIX jobs: shell-spawn npm and CRLF-pin the VSIX legal files (unblocks v0.37 release)#346
Merged
Conversation
…X legal files The win32 VSIX jobs in the v0.37.2 release died in licenses:check because update-dependency-licenses.mjs spawned 'npm' via execFileSync — on Windows npm is npm.cmd and needs a shell, so the spawn failed ENOENT. Spawn npm.cmd through a shell on win32 (static arguments only). Behind that spawn the same jobs would then have hit the CRLF checkout problem fixed for the typeshed index in #344: the --check mode byte-compares the committed VSCODE-DEPENDENCY-LICENSES and vscode-license-manifest.json against regenerated LF bytes, and VSCODE-DISTRIBUTION-LICENSE ships verbatim into the VSIX as LICENSE.txt. Pin all three -text and add them to the checkout byte-stability guard so an unpinned byte-verified file keeps failing PR CI, not the release.
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.
TLDR
Fixes the failure that stopped the v0.37.2 release at the Windows VSIX jobs —
licenses:checkspawningnpmin a way Windows cannot execute — and defuses the CRLF checkout landmine sitting directly behind it in the same jobs.What Was Added?
VSIX_LEGAL_FILESinscripts/verify_release_attribution.py:VSCODE-DISTRIBUTION-LICENSE,VSCODE-DEPENDENCY-LICENSES, andvscode-license-manifest.jsonjoin the checkout byte-stability guard added in Fix v0.36/v0.37 release failures: CRLF-proof byte-verified typeshed index + native linux-arm64 wheel build #344, since the VSIX pipeline byte-compares/ships them (update-dependency-licenses.mjs --checkrequires the committed carrier + manifest to equal regenerated LF bytes; the distribution license is packed verbatim into the VSIX asLICENSE.txt)..gitattributes-textpins for those three files.What Was Changed or Deleted?
vscode-extension/scripts/update-dependency-licenses.mjsspawnsnpm.cmdthrough a shell on Windows (static arguments only). On win32 npm is a.cmd, which Node cannot spawn directly —execFileSync("npm", …)failed withspawnSync npm ENOENT, killing both win32 VSIX jobs in the v0.37.2 release run (first-ever execution of this check on Windows; it was added after v0.35.0 with the VSIX license carrier work).How Do The Automated Tests Prove It Works?
python3 scripts/verify_release_attribution.py --policy-onlyfails withVSCODE-DISTRIBUTION-LICENSE is byte-verified but not pinned '-text' in .gitattributes; with the pins it passes. CI runs that exact command on every PR.npm run licenses:checkstill reportsVS Code production dependency licenses are exacton POSIX after the spawn change, and eslint passes.release.yml).Breaking Changes