Speed up Windows functional tests by using the D: drive

[schlessera]

What

Two changes to the Windows functional (Behat) job:

1. A Windows-only step (before checkout) that redirects TEMP/TMP to D:\Temp, guarded to be a no-op if the D: drive is unavailable.
2. Pins the Windows matrix entry to windows-2022 (the D: drive was removed from windows-2025).

No changes to Linux/macOS jobs.

Why

The Windows functional job is by far the slowest in the matrix (well over an hour vs ~30 min on Linux for the same 262 scenarios). Nearly all of it is the Behat run: each scenario installs WordPress and spawns many short-lived wp/php processes, and on the Windows runner that file I/O all happens on the slow C: drive. GitHub's Windows runners have a read-optimized (slow) C: drive and a fast D: working drive.

Because the wp-cli-tests framework derives the WP install directory (RUN_DIR), the core/install/SQLite caches, and HOME/COMPOSER_HOME (the WP-CLI cache) all from sys_get_temp_dir(), and forwards TEMP/TMP to the spawned wp processes, a single TEMP/TMP redirect relocates everything onto D:.

Measurements

Measured on extension-command (PHP 8.5 / WP trunk / SQLite), every run a full 262/262-scenario clean pass:

Config	Behat run (min)
windows-2022, temp on C: (baseline)	~74.8
windows-2022, temp on D: (this PR)	23, 25, 43, 43
windows-latest (2025), no D:	~79–104

Redirecting to D: roughly halves the Behat time. Windows runner performance is highly variable (bimodal, ~24 or ~43 min depending on the Azure host), so the result is a band rather than a single number, but the ~2x improvement clears the variance comfortably.

Alternatives considered and rejected

• OPcache file cache on D: no measurable benefit (same-batch A/B: 42.9 min without vs 45.4 min with, i.e. slightly worse). Each scenario installs WordPress at a unique temp path, so opcache.file_cache misses across scenarios; only the stable-path framework code is reused, which is negligible, while the bytecode serialization adds a little overhead. Left out to keep the change simple.
• Dev Drive (ReFS VHDX) on windows-latest: ~90 min, far slower than the physical D: drive, so it does not recover the win on windows-2025.
• Windows Defender tweaks: already ruled out separately (real-time protection is off on these runners); see Revert Windows Defender step (no-op on GitHub runners) #268.

Notes

• The Windows job is continue-on-error (informational), so this only changes how long it takes, not whether it can block a PR.
• Pinning to windows-2022 trades newest-image coverage for the D: drive; the job exists to catch Windows-specific breakage rather than to track the latest Windows image, and windows-2025 is both slower and lacks the D: drive.
• The .github repo doesn't run functional tests against itself; the numbers above come from pointing a package's testing.yml at this branch.

Summary by CodeRabbit

• Tests
  • Improved Windows test execution by using a consistent Windows 2022 environment.
  • Optimized temporary file handling during Windows functional tests by redirecting temp storage to a faster drive when available.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 55841e2a-5ba3-4b71-8720-e7441190b43c

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• ✅ Review completed - (🔄 Check again to review again)

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch windows-ci-use-d-drive

---

_{Comment @coderabbitai help to get the list of available commands.}

[swissspidy]

2. Pins the Windows matrix entry to windows-2022 (the D: drive was removed from windows-2025).

@schlessera Is this really true?

See

1. [Windows Server 2025] image will no longer have D:/ drive accessible to users from 2025-07-14 actions/runner-images#12416
2. [Windows Server 2025] image will again have D:/ drive accessible to users from 2025-08-18 actions/runner-images#12744

So according to this, the D: drive should be available on windows-2025.

And if not, then I am worried about what we do once windows-2022 is deprecated.

[schlessera]

@swissspidy Let me test this.

[schlessera]

@swissspidy So the D: drive is indeed back and working on windows-latest. However, my testing currently indicates that it is slower than the D: drive on windows-2022. So I'd leave it at windows-2022 for now - we can always switch to windows-latest if the old version gets removed.