Skip to content

ci: run Windows jobs on Namespace runners#2083

Merged
fengmk2 merged 10 commits into
mainfrom
ci/namespace-windows-runners
Jul 8, 2026
Merged

ci: run Windows jobs on Namespace runners#2083
fengmk2 merged 10 commits into
mainfrom
ci/namespace-windows-runners

Conversation

@fengmk2

@fengmk2 fengmk2 commented Jul 7, 2026

Copy link
Copy Markdown
Member

Run the Windows CI and release jobs on Namespace runners, matching how Linux and macOS already do, except for the handful of jobs that depend on GitHub-hosted Windows behavior.

What changed

Swap windows-latest -> namespace-profile-windows-4c-8g (4 vCPU / 8 GB) for the Windows jobs in ci.yml, e2e-test.yml, test-standalone-install.yml, and reusable-release-build.yml (x86_64 native + aarch64 cross-compiled on the amd64 host). Windows-specific if: conditions move from matrix.os == 'windows-latest' to the label-independent runner.os == 'Windows', and e2e-test's exclude rules follow the new label.

Prerequisite

The windows-4c-8g profile (Windows Server 2022, amd64) must exist in the Namespace dashboard, otherwise these jobs queue instead of running.

Namespace service-account accommodation

Namespace's Windows runners execute jobs under a Session-0 service account whose real user profile is C:\Windows\system32\config\systemprofile, not %USERPROFILE% (GitHub-hosted windows-latest runs as an interactive user where the two match). For the install jobs that only check shim placement, pinning VP_HOME=%USERPROFILE%\.vite-plus is enough, so test-install-ps1-v5/-v76 and test-vp-setup-exe stay on Namespace. The install version pin was also dropped so the scripts install latest instead of the stale alpha dist-tag.

Kept on GitHub-hosted windows-latest (with inline rationale comments)

  • windows-11-arm install test: Namespace has no Windows ARM64.
  • cli-snapshot-test-windows: a PTY snapshot suite. The runner opens a pseudo-console (ConPTY) and spawns vp into it; under the Session-0 service account (no interactive console) that spawn blocks, vp never launches, and every case times out at 60s. Verified via a temporary debug workflow: the vp process count stays 0 for the full 60s.
  • test-install-ps1 (plain): runs vp env doctor under bash set -e; on the service account vp resolves the systemprofile home even with VP_HOME set, so doctor's PATH check fails.

reusable-release-build.yml still needs the MSVC toolchain (VS Build Tools + Windows SDK) present on the Namespace image; watch that job's first green run.

Runner speed (before vs after)

The Windows run-only jobs are roughly 2x faster on Namespace than on windows-latest. Same job content (they download prebuilt binaries and run tests), only runs-on changed, so this is purely the runner. Sampled across two CI run pairs (windows-latest on main vs Namespace on this PR):

Job (switched to Namespace) windows-latest Namespace 4c/8g Speedup
Test (Windows) 3m01s / 3m34s 1m42s / 1m51s ~46%
CLI E2E test (Windows) 3m59s / 5m07s 2m17s / 2m04s ~50%
CLI snap test 1/3 3m54s / 4m00s 2m08s / 2m09s ~46%
CLI snap test 2/3 4m04s / 6m50s 2m28s / 2m26s ~52%
CLI snap test 3/3 4m47s / 5m03s 2m14s / 2m30s ~52%

Summed, those jobs drop from ~19m45s to ~10m49s of Windows-runner time per run, despite the Namespace shape having less RAM (8 GB vs 16 GB). Not part of this comparison: Build Windows CLI/tests already cross-compile on Namespace Linux (unchanged), and cli-snapshot-test-windows, windows-11-arm, and test-install-ps1 (plain) stay on windows-latest.

@netlify

netlify Bot commented Jul 7, 2026

Copy link
Copy Markdown

Deploy Preview for viteplus-preview canceled.

Name Link
🔨 Latest commit c9e4d34
🔍 Latest deploy log https://app.netlify.com/projects/viteplus-preview/deploys/6a4e74f07935cc000898fc7a

fengmk2 commented Jul 7, 2026

Copy link
Copy Markdown
Member Author

How to use the Graphite Merge Queue

Add the label auto-merge to this PR to add it to the merge queue.

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

@fengmk2 fengmk2 added the preview-build Publish this PR's commits to the registry bridge as preview builds label Jul 8, 2026
@github-actions

github-actions Bot commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

Registry bridge build (e833057)

This commit build is published to the registry bridge, which serves these as ordinary npm versions (every other package proxies to npmjs):

Package Version
vite-plus 0.0.0-commit.e833057f2e9462c421d346ca2a4d9356743f90b1
@voidzero-dev/vite-plus-core 0.0.0-commit.e833057f2e9462c421d346ca2a4d9356743f90b1

Install the Vite+ CLI built from this commit, then migrate a project:

# macOS / Linux
curl -fsSL https://vite.plus | VP_PR_VERSION=2083 bash
# Windows (PowerShell)
$env:VP_PR_VERSION="2083"; irm https://vite.plus/ps1 | iex

After installing, upgrade the current project's vite-plus to this test build with:

vp migrate

Or point your package manager at the bridge registry https://registry-bridge.viteplus.dev/:

Package manager Registry config
npm / pnpm / Bun .npmrc: registry=https://registry-bridge.viteplus.dev/
Yarn (v2+) .yarnrc.yml: npmRegistryServer: "https://registry-bridge.viteplus.dev/"

Then pin the build (vite aliases to vite-plus-core; pnpm can use a catalog, npm an overrides entry):

{
  "devDependencies": {
    "vite-plus": "0.0.0-commit.e833057f2e9462c421d346ca2a4d9356743f90b1",
    "vite": "npm:@voidzero-dev/vite-plus-core@0.0.0-commit.e833057f2e9462c421d346ca2a4d9356743f90b1"
  }
}

@github-actions

github-actions Bot commented Jul 8, 2026

Copy link
Copy Markdown
Contributor

🐳 Docker preview image

Built from this PR's registry bridge build:

Image Compressed size
ghcr.io/voidzero-dev/vite-plus:pr-2083 240MB
# remove any stale local copy from a previous run, then pull fresh
docker rmi ghcr.io/voidzero-dev/vite-plus:pr-2083 2>/dev/null; docker pull ghcr.io/voidzero-dev/vite-plus:pr-2083

Quick check:

docker run --rm ghcr.io/voidzero-dev/vite-plus:pr-2083 vp --version

See docs/guide/docker.md for usage.

@fengmk2 fengmk2 force-pushed the ci/namespace-windows-runners branch 2 times, most recently from 5c22f67 to 2d352fe Compare July 8, 2026 14:35
@fengmk2

fengmk2 commented Jul 8, 2026

Copy link
Copy Markdown
Member Author

@codex review

fengmk2 added 9 commits July 8, 2026 23:38
Swap windows-latest -> namespace-profile-windows-x64-default for the movable Windows jobs in ci.yml, e2e-test.yml, and test-standalone-install.yml, matching how Linux and macOS already use Namespace profiles. Windows-specific if: conditions move from matrix.os == 'windows-latest' to the label-independent runner.os == 'Windows', and e2e-test's exclude rules follow the new label.

Left on GitHub-hosted runners: the windows-11-arm install test (Namespace has no Windows ARM64) and reusable-release-build.yml (ships MSVC-native user binaries). Requires a namespace-profile-windows-x64-default profile (Windows Server 2022, amd64) in the Namespace dashboard.
Switch the Windows runs-on labels from a namespace-profile-* label to the inline nscloud-windows-2022-amd64-8x16 form. Inline labels need no Namespace dashboard profile (they work as long as the repo is connected to Namespace), so this drops the one-time dashboard setup. Shape 8x16 (8 vCPU / 16 GB) matches windows-latest RAM and doubles the cores.
Switch the Windows runs-on labels to the dashboard profile namespace-profile-windows-4c-8g (4 vCPU / 8 GB), matching the namespace-profile-* style already used for Linux and macOS. Requires that profile to exist in the Namespace dashboard.
Move reusable-release-build.yml's two Windows targets (x86_64 native, aarch64 cross-compiled on the amd64 host) from windows-latest to namespace-profile-windows-4c-8g. The release build needs the native MSVC toolchain (VS Build Tools + Windows SDK) on the runner image.
…ere tests check

Namespace's Windows runners execute jobs under a service account whose real user profile (C:\Windows\system32\config\systemprofile) differs from %USERPROFILE% (C:\Users\runneradmin). vp resolves its home from the OS profile, so install.ps1 placed vp.exe under %USERPROFILE%\.vite-plus while 'vp env setup' wrote node/npm/npx shims into the systemprofile home, and the assertions checking %USERPROFILE%\.vite-plus\bin failed with 'Shim not found'. vp-setup.exe and the snapshot suite's VP_SNAP_* paths hit the same split.

Pin VP_HOME to %USERPROFILE%\.vite-plus in the five affected jobs (test-install-ps1-v5/-v76/plain, test-vp-setup-exe, cli-snapshot-test-windows) so the install, generated shims, and assertions share one location. Also switch the PowerShell 7.6 job's 'dotnet tool install' from --global (resolves under the systemprofile) to an explicit --tool-path.
The standalone-install tests pinned VP_VERSION to the alpha dist-tag, which is stale (0.1.21-alpha.7, published 2026-05-13) and predates the VP_HOME fix in #2029 (2026-07-05). On Namespace's service-account Windows runners that old binary's 'vp env doctor' ignores VP_HOME and resolves the systemprofile home, failing the plain test-install-ps1 job. Drop VP_VERSION entirely so install.ps1/install.sh/vp-setup.exe default to latest (a build that contains #2029), which also lets the tests track releases instead of a hardcoded version.
…pace

Reproduces cli-snapshot-test-windows's 60s hangs on namespace-profile-windows-4c-8g with two instrumented probes: (1) bare vp --help under an isolated empty VP_HOME + VITE_LOG=trace with a hard 30s wait and a CPU sampler (empty VP_HOME is the variable the passing cli-e2e-test job doesn't exercise; distinguishes a self-exec spin from a blocked prompt), and (2) the single help::global case through the PTY runner with --no-capture. Trigger via push to this file or workflow_dispatch. Remove before merge.
Probe 1 (bare vp --help, empty VP_HOME, no PTY) exits 0 with full help; Probe 2 (same case via the PTY runner) hangs 60s with ZERO output, before vp's first trace line, so vp wedges at ConPTY startup. Rework Probe 2 to launch nextest in the background and sample vp/node process count + CPU in the foreground (the earlier '&'-backgrounded sampler output was never captured), to distinguish a self-exec spin (rising CPU / many vp procs) from a blocked ConPTY read (flat CPU, one vp).
Two Windows jobs cannot run on Namespace Session-0 service-account runners and move back to windows-latest, with code comments explaining why.

cli-snapshot-test-windows is a PTY snapshot suite: the runner opens a ConPTY and spawns vp into it; under the Session-0 service account (no interactive console) that spawn blocks, vp never launches, and every case times out at 60s (verified: the vp process count stays 0 for the full 60s).

test-install-ps1 (plain) runs vp env doctor under bash set -e; on the service account the installed vp resolves the systemprofile home rather than %USERPROFILE% even with VP_HOME set, so the doctor PATH check fails. The other install jobs stay on Namespace because they do not run doctor under set -e.

Also removes the temporary debug-snapshot-hang.yml workflow used to diagnose the ConPTY hang.
@fengmk2 fengmk2 force-pushed the ci/namespace-windows-runners branch from 47ae5ff to e833057 Compare July 8, 2026 15:39
@fengmk2 fengmk2 added test: e2e Auto run e2e tests test: install-e2e run vite install e2e test test: create-e2e Run `vp create` e2e tests preview-build Publish this PR's commits to the registry bridge as preview builds and removed preview-build Publish this PR's commits to the registry bridge as preview builds labels Jul 8, 2026

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 47ae5ffcb6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread .github/workflows/ci.yml
Comment thread .github/workflows/test-standalone-install.yml
Comment thread .github/workflows/ci.yml
setup-dev-drive v4 mounts its ReFS VHD on namespace-profile-windows-4c-8g and all three cli-snap-test Windows shards pass with the step succeeding, so the shards stay on Namespace. Documents this inline in response to review feedback.
@fengmk2

fengmk2 commented Jul 8, 2026

Copy link
Copy Markdown
Member Author

@codex review

@chatgpt-codex-connector

Copy link
Copy Markdown

Codex Review: Didn't find any major issues. What shall we delve into next?

Reviewed commit: c9e4d34643

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@fengmk2 fengmk2 marked this pull request as ready for review July 8, 2026 16:12
@fengmk2 fengmk2 merged commit 63f837b into main Jul 8, 2026
114 checks passed
@fengmk2 fengmk2 deleted the ci/namespace-windows-runners branch July 8, 2026 16:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

preview-build Publish this PR's commits to the registry bridge as preview builds test: create-e2e Run `vp create` e2e tests test: e2e Auto run e2e tests test: install-e2e run vite install e2e test

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants