ci: add Windows Defender disable to e2e-test.yml

[fengmk2]

Summary

Add Windows Defender real-time scanning disable to e2e-test.yml Windows jobs, which previously had no Windows I/O optimization.

Changes

e2e-test.yml — Add Defender disable (new)

• Build job (windows-latest): Added Set-MpPreference -DisableRealtimeMonitoring $true
• E2E test jobs (windows-latest): Added Defender disable for vp install, test execution, etc.

ci.yml — No change

Test and CLI E2E jobs already had Defender disable from PR #716.

Expected Impact

Job	Before	After (expected)
E2E Build (Windows)	~4m18s	~3-4min
E2E tests (Windows)	baseline	~20-30% faster I/O

Notes

Dev Drive (setup-dev-drive) was also tested in this PR but reverted — it caused cargo target directory cache invalidation due to workspace path changes, resulting in full rebuilds. See comparison comment for details. The simpler Defender-disable approach is sufficient.

[netlify]

✅ Deploy Preview for viteplus-staging canceled.

Name	Link
🔨 Latest commit	27fcb86
🔍 Latest deploy log	https://app.netlify.com/projects/viteplus-staging/deploys/69ad4a4ae1a9870008934d11

[fengmk2]

CI Speed Comparison: Before vs After

⚠️ Dev Drive (workspace-copy: true) caused a regression on Test (Windows)

The workspace-copy: true flag moves the workspace to the Dev Drive, which changes the workspace path and invalidates the oxc-project/setup-rust target directory cache. This caused a full recompile.

Test (Windows) — ❌ Regression (6min → 18min)

Step	Before (Defender disable)	After (Dev Drive)	Delta
Defender / Dev Drive setup	1s	48s	+47s (one-time)
setup-rust (cache restore)	1m27s	19s	✅ -1m8s
cargo check	2m14s	10m14s	❌ +8m (cold cache!)
cargo test	1m53s	6m2s	❌ +4m9s (cold cache!)
Total	6m9s	18m12s	❌ +12m (+197%)

The cache restore was faster (19s vs 1m27s — registry on ReFS is fast), but the target directory cache was invalidated because the workspace path changed from C:\... to the Dev Drive path. This forced a full rebuild.

CLI E2E (Windows) — ❌ Slight regression (9m38s → 11m53s)

Step	Before (Defender disable)	After (Dev Drive)	Delta
Dev Drive setup	2s	43s	+41s
setup-rust	47s	20s	✅ -27s
setup-node	1m10s	1m41s	-31s
Build upstream	1m30s	1m40s	-10s
Snapshot tests	3m51s	4m48s	-57s
Total	9m38s	11m53s	❌ +2m15s

E2E Build (Windows) — ⏸️ Minimal change (Defender disable only)

Metric	Before (no optimization)	After (Defender disable)
Total	4m18s	4m6s

Defender disable showed ~12s improvement, marginal.

Root Cause

workspace-copy: true changes GITHUB_WORKSPACE to the Dev Drive. The oxc-project/setup-rust action caches the target/ directory keyed to the original workspace path, so the cache becomes a miss. This means every run does a full Rust rebuild.

Fix Options

1. Remove workspace-copy: true — Only map CARGO_HOME and RUSTUP_HOME to the Dev Drive (like rolldown does). The workspace stays on C: drive, cache works normally, and cargo registry I/O still benefits.

2. Revert to Defender-only — The simpler Set-MpPreference approach was already working well for this repo.

I'll push a fix with option 1 (matching rolldown's approach) to see if it preserves the cache while still benefiting from the Dev Drive for cargo/rustup.

[fengmk2]

v2 Results (Defender + Dev Drive, no workspace-copy)

Test (Windows) — 16m22s (still cold cache)

Step	Baseline (Defender only)	v2 (Defender + Dev Drive)
Defender disable	1s	2s
Dev Drive setup	—	14s
setup-rust (cache)	1m27s	17s ✅
cargo check	2m14s	8m31s ❌
cargo test	1m53s	6m23s ❌
Total	6m9s	16m22s

CLI E2E (Windows) — 10m20s (slight regression)

Step	Baseline	v2
setup-rust	47s	25s ✅
setup-node	1m10s	1m46s
Build upstream	1m30s	1m34s
Snapshot tests	3m51s	3m41s
Total	9m38s	10m20s

Analysis

The cargo target directory cache is still cold — the v1 run with workspace-copy: true saved the cache under a different workspace path. Since save-cache only runs on main, this PR branch can't warm the cache. The setup-rust cache restore (17s vs 1m27s) confirms the Dev Drive is faster for registry I/O.

Recommendation

The Dev Drive adds complexity (~14s setup) but the main benefit (faster cache restore) is modest. Given that:

1. The cargo target cache invalidation caused a multi-run cold cache penalty
2. The baseline with just Defender disable was already performing well (6min)
3. The Dev Drive benefit without workspace-copy is limited to CARGO_HOME/RUSTUP_HOME

I suggest simplifying: revert to Defender-disable only (remove the Dev Drive step). The Set-MpPreference approach is simpler, proven, and avoids cache invalidation risk. Keep only the Defender disable additions for e2e-test.yml.

Want me to push this simplification?