Revert Windows Defender step (no-op on GitHub runners) - #268
Merged
Conversation
PR #267 added a step to disable Windows Defender real-time scanning on the Windows functional job, on the theory that Defender's per-process scanning was responsible for the Windows runner being several times slower than Linux. Measuring it showed no effect (79 vs 84 minutes for the same suite, within Windows runner variance). A `Get-MpComputerStatus` probe on the runner explains why: GitHub's `windows-latest` image already ships with `RealTimeProtectionEnabled: False` and `IsTamperProtected: False`, so `Set-MpPreference -DisableRealtimeMonitoring` has nothing to turn off and is a no-op. The real cost is inherent to running the process-heavy Behat suite on Windows (short-lived `wp`/`php` process spawning, PHP cold-start and NTFS file I/O per scenario), which no Defender setting can address. Remove the misleading step. Reducing what runs on Windows (the job is already `continue-on-error`) is the lever that actually helps, and can be pursued separately.
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe reusable functional testing workflow removes the Windows-only step that disabled Microsoft Defender real-time scanning. Checkout, setup, database, Behat, and optional coverage steps remain unchanged. ChangesFunctional testing workflow
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Member
|
Bummer! |
swissspidy
approved these changes
Jul 21, 2026
schlessera
marked this pull request as ready for review
July 21, 2026 14:34
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
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.
Reverts the Defender step added in #267.
Why
#267 disabled Windows Defender real-time scanning on the Windows functional job, on the theory that Defender's per-process scanning was making the Windows runner several times slower than Linux. Measuring it showed no effect: ~79 min vs ~84 min for the same suite, within Windows runner variance.
A
Get-MpComputerStatusprobe on the runner explains why:GitHub's
windows-latestimage already ships with real-time protection off, soSet-MpPreference -DisableRealtimeMonitoring(and anAdd-MpPreference -ExclusionPathfallback) have nothing to turn off. The step is a no-op and misleads future maintainers into thinking Windows Defender is handled.What's actually slow
Effectively all of the Windows job time is the single
Run Behatstep (~80 min; setup is ~2 min), and it's uniform per-scenario overhead rather than one slow test. That's inherent to running the process-heavy Behat suite on Windows: short-livedwp/phpprocess spawning, PHP cold-start, and NTFS file I/O per scenario. No Defender setting addresses it.The job is already
continue-on-error(informational, never blocks a PR). The lever that would actually cut wall-clock is running less on Windows (a tagged smoke subset) or sharding it, which can be pursued separately.Summary by CodeRabbit