The Windows file system seems to be a lot slower when restoring e.g. cached
node_modules folders than Linux and MacOS, resulting in frequent failing builds due to timeout. Example:
In that example the Node.js 12 build on Windows just barely made it to restore the cache in 10min while the Node.js 10 ran into the timeout. I wouldn’t know how to add
travis_wait, but either allowing this or producing some
...-progress output by default would be appreciated. Or making Windows file system faster…
We’re seeing the same issue, not sure if this is new but lately all of our windows builds timeout on cache restore. This is a pretty tiny project too. Just deleted the cache and it seems to be working again.
Would like to see this get fixed!
Can confirm getting the same thing. Is quite frustrating
Comparing the new download logic (only on Windows by default) with the old one (used on Linux and macOS by default), I can see that the old one used to disable Nagle’s algorithm while the new one doesn’t. Might be a reason for delays.
EDIT: As found in this other post, Windows Defender is responsible for a large chunk of the slowness. Normally you’d disable it with PowerShell commands like:
Set-MpPreference -DisableArchiveScanning $true
Set-MpPreference -DisableRealtimeMonitoring $true
Set-MpPreference -DisableBehaviorMonitoring $true
… but in this case you have to execute these commands at startup, before the cache restore starts. I accomplished this by backticking the commands into environment variables:
Set-MpPreference -DisableArchiveScanning \\\$true`
Set-MpPreference -DisableRealtimeMonitoring \\\$true`
Set-MpPreference -DisableBehaviorMonitoring \\\$true`
Now the whole build (not just the cache restore) runs much faster.
Seems to work, nice trick! I’m going to add this to Gravis-CI!
You took it to the next level! Thanks!
I’ve tested @tanzislam’s idea with a fork of @bkimminich’s repo.
Here’s the “happy” build: https://staging.travis-ci.org/BanzaiMan/juice-shop/builds/747916.
Compared to the previous build https://staging.travis-ci.org/BanzaiMan/juice-shop/builds/747914 (which created the cache), the build time is 2 minutes shorter.
With the production code with no tinkering with Windows Defender, https://staging.travis-ci.org/BanzaiMan/juice-shop/builds/747918 fails to expand the cache.
The PR above has been merged and deployed. Please report any result (hopefully good ones!) that you may find.