It is far too common nowadays that one build on our buildbot will end up corrupting all future builds, requiring a manual login to the bot to fix the state of affairs. The most common reason this happens is a rogue process remains running on Windows, preventing recreation of the executable (e.g. causing the compiler to fail to link on all future test runs).
It would likely be much more robust to start a new slave each time we start a new build. This way we're guaranteed a 100% clean slate when starting a build (e.g. no lingering processes). This would, however, require caching LLVM builds elsewhere and having the first step of the build to download the most recent LLVM build.
As such, this is not an easy bug to implement at all, hence the wishlist status for our infrastructure.
cc @brson
It is far too common nowadays that one build on our buildbot will end up corrupting all future builds, requiring a manual login to the bot to fix the state of affairs. The most common reason this happens is a rogue process remains running on Windows, preventing recreation of the executable (e.g. causing the compiler to fail to link on all future test runs).
It would likely be much more robust to start a new slave each time we start a new build. This way we're guaranteed a 100% clean slate when starting a build (e.g. no lingering processes). This would, however, require caching LLVM builds elsewhere and having the first step of the build to download the most recent LLVM build.
As such, this is not an easy bug to implement at all, hence the wishlist status for our infrastructure.
cc @brson