From 355b2d5e9cef8388fd49525301021854a2e40f2b Mon Sep 17 00:00:00 2001 From: Den Kong Date: Sat, 5 Sep 2026 17:17:34 +0800 Subject: [PATCH] Fix the windows arms of the release build scripts Every hunk here is in a branch only windows takes, and windows has never built a release, so none of them has ever run. They are what stands between `OS=windows npm run release` and a tarball. Nothing off windows changes: the first two are inside a windows-only case, the third adds a test around a copy, the fourth excludes a file no other platform has, and the fifth adds windows to a condition it was missing from. 1. The remote-cli launcher is named after product.applicationName, which this repository overrides to code-server, so what gulp writes is remote-cli/code-server.cmd. The windows arm asked for remote-cli/code.cmd, which is the name of the template it is built from. The posix arm four lines below already spells it code-server. See lib/vscode build/gulpfile.reh.ts, the platform === 'win32' arm: rename(`bin/remote-cli/${product.applicationName}.cmd`). 2. fix-bin-script rewrites the launcher's root to the release root and then has to send the two things still living in the vscode tree back down again. It does that for out/ on both platforms, and for the node binary only on posix, where the third sed rewrites $ROOT/node to $ROOT/lib/node. The windows half had no counterpart, so the .cmd launchers looked for node.exe at the release root while build-release.sh puts it in lib. NODE_EXEC_PATH, which the posix rewrite also honours, has no equivalent on this side and is not invented here. 3. The node binary is called node.exe on windows -- gulpfile.reh.ts renames it in the same win32 arm as above -- so this copy asked for a file that is not there and took the whole release step down with it under set -e. 4. The same name again, in the exclusion that keeps node out of lib/vscode because it belongs one directory above. /node does not match node.exe, so on windows the binary was copied into lib/vscode as well as being placed above it. 5. build-packages.sh renames the tree's top directory as it archives, and reaches for bsdtar's -s off linux because that is what macos has. The bsdtar windows ships is built without substitution support: it answers "-s is not supported by this version of bsdtar" and its --help lists no such option. So windows belongs on the GNU --transform arm. Checked against both, bsdtar 3.7.7 and GNU tar 1.34. Verified by building a windows release with these applied and then running what came out: the server serves, the extension host starts, and a terminal in the workbench round-trips a command. For 2 specifically, the built launcher reads call "%ROOT_DIR%\lib\node.exe" ... with ROOT_DIR at the release root, and node is at lib/node.exe; running it reaches node and gets server-cli.js's own "only available in WSL or inside a Visual Studio Code terminal", exit 0. Putting that one path back the way it was gives '...\remote-cli\..\..\..\..\node.exe' is not recognized, exit 1. What is not covered is the launcher's later behaviour against a live server, which needs VSCODE_IPC_HOOK_CLI set by a workbench terminal. --- ci/build/build-packages.sh | 2 +- ci/build/build-release.sh | 7 ++++++- ci/build/build-vscode.sh | 3 ++- 3 files changed, 9 insertions(+), 3 deletions(-) diff --git a/ci/build/build-packages.sh b/ci/build/build-packages.sh index 35b27a558edc..dfd29dba20d3 100755 --- a/ci/build/build-packages.sh +++ b/ci/build/build-packages.sh @@ -25,7 +25,7 @@ main() { release_archive() { local release_name="code-server-$VERSION-$OS-$ARCH" - if [[ $OS == "linux" ]]; then + if [[ $OS == "linux" || $OS == "windows" ]]; then tar -czf "release-packages/$release_name.tar.gz" --owner=0 --group=0 --transform "s/^$RELEASE_PATH/$release_name/" "$RELEASE_PATH" else tar -czf "release-packages/$release_name.tar.gz" -s "/^$RELEASE_PATH/$release_name/" "$RELEASE_PATH" diff --git a/ci/build/build-release.sh b/ci/build/build-release.sh index 6dbc2784acbc..071f438b6d74 100755 --- a/ci/build/build-release.sh +++ b/ci/build/build-release.sh @@ -111,6 +111,7 @@ bundle_vscode() { # Exclude Node since we want to place it in a directory above. rsync_opts+=(--exclude /node) + rsync_opts+=(--exclude /node.exe) # Exclude Node modules. Note that these will already only include production # dependencies, so if we do keep them there is no need to do any @@ -123,7 +124,11 @@ bundle_vscode() { # Copy the Node binary. if [[ $KEEP_MODULES = 1 ]]; then - cp "./lib/vscode-reh-web-$VSCODE_TARGET/node" "$RELEASE_PATH/lib" + if [ "$OS" = windows ]; then + cp "./lib/vscode-reh-web-$VSCODE_TARGET/node.exe" "$RELEASE_PATH/lib" + else + cp "./lib/vscode-reh-web-$VSCODE_TARGET/node" "$RELEASE_PATH/lib" + fi fi # Merge the package.json for the web/remote server so we can include diff --git a/ci/build/build-vscode.sh b/ci/build/build-vscode.sh index 871a801aa30f..a7db93a1a177 100755 --- a/ci/build/build-vscode.sh +++ b/ci/build/build-vscode.sh @@ -24,6 +24,7 @@ fix-bin-script() { # Fix Node path on Windows. sed -i.bak 's/^set ROOT_DIR=\(.*\)$/set ROOT_DIR=%~dp0..\\..\\..\\..\r\nset VSROOT_DIR=\1/g' "$script" sed -i.bak 's/%ROOT_DIR%\\out/%VSROOT_DIR%\\out/g' "$script" + sed -i.bak 's/%ROOT_DIR%\\node.exe/%ROOT_DIR%\\lib\\node.exe/g' "$script" chmod +x "$script" rm "$script.bak" @@ -132,7 +133,7 @@ EOF # Set vars and fix paths. case $OS in windows) - fix-bin-script remote-cli/code.cmd + fix-bin-script remote-cli/code-server.cmd fix-bin-script helpers/browser.cmd ;; *)