ci: run Windows jobs on Namespace runners#2083
Merged
Merged
Conversation
✅ Deploy Preview for viteplus-preview canceled.
|
Member
Author
How to use the Graphite Merge QueueAdd 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
added
the
preview-build
Contributor
Registry bridge build (
|
| 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 | iexAfter installing, upgrade the current project's vite-plus to this test build with:
vp migrateOr 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"
}
}
Contributor
🐳 Docker preview imageBuilt from this PR's registry bridge build:
# 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-2083Quick check: docker run --rm ghcr.io/voidzero-dev/vite-plus:pr-2083 vp --versionSee docs/guide/docker.md for usage. |
wan9chi
approved these changes
Jul 8, 2026
fengmk2
force-pushed
the
ci/namespace-windows-runners
branch
2 times, most recently
from
5c22f67 to
2d352fe
Compare
Member
Author
|
@codex review |
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
force-pushed
the
ci/namespace-windows-runners
branch
from
47ae5ff to
e833057
Compare
fengmk2
added
test: e2e
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 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".
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.
Member
Author
|
@codex review |
|
Codex Review: Didn't find any major issues. What shall we delve into next? Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
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
2 participants
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.
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 inci.yml,e2e-test.yml,test-standalone-install.yml, andreusable-release-build.yml(x86_64 native + aarch64 cross-compiled on the amd64 host). Windows-specificif:conditions move frommatrix.os == 'windows-latest'to the label-independentrunner.os == 'Windows', ande2e-test'sexcluderules follow the new label.Prerequisite
The
windows-4c-8gprofile (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-hostedwindows-latestruns as an interactive user where the two match). For the install jobs that only check shim placement, pinningVP_HOME=%USERPROFILE%\.vite-plusis enough, sotest-install-ps1-v5/-v76andtest-vp-setup-exestay on Namespace. The install version pin was also dropped so the scripts installlatestinstead of the stalealphadist-tag.Kept on GitHub-hosted windows-latest (with inline rationale comments)
windows-11-arminstall 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): runsvp env doctorunder bashset -e; on the service account vp resolves the systemprofile home even withVP_HOMEset, so doctor's PATH check fails.reusable-release-build.ymlstill 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), onlyruns-onchanged, so this is purely the runner. Sampled across two CI run pairs (windows-latest onmainvs Namespace on this PR):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/testsalready cross-compile on Namespace Linux (unchanged), andcli-snapshot-test-windows,windows-11-arm, andtest-install-ps1(plain) stay onwindows-latest.