Add a new clang-x64-windows-msvc-forward-slashes builder.#746
Add a new clang-x64-windows-msvc-forward-slashes builder.#746
Conversation
4b9923c to
647397f
Compare
This builder is designed to be run to ensure that clang passes tests when -DLLVM_WINDOWS_PREFER_FORWARD_SLASH is enabled.
647397f to
4c603cd
Compare
|
|
||
| {'name' : 'clang-x64-windows-msvc-forward-slashes', | ||
| 'tags' : ["clang"], | ||
| 'workernames' : ['windows-gcebot2'], |
There was a problem hiding this comment.
This reuses an existing worker. I assumed this was fine since the intent was to run this builder infrequently. Please tell me if this isn't the case.
There was a problem hiding this comment.
Builders don't run infrequently. They run as often as possible, up to doing a run on every commit. The original suggestion in the PR was to update the configuration of one of these builders, not add a new builder (from what I understand).
There was a problem hiding this comment.
From what I can tell, there are mostly only two options for builders to reuse. The clang x64 windows builder, and the clang arm64 windows builder. We could modify an existing builder, though there'd be concerns that the builder would immediately start failing because the tests are not yet passing.
How would people feel about using the clang arm64 windows builder? We appear to have two of them - a 1 stage, and a 2 stage?
There was a problem hiding this comment.
You'd have to ping one of the owners of that bot. Ideally the configuration should be green before switching a buldbot over to it.
| script="clang-windows.py", | ||
| depends_on_projects=['llvm', 'clang', 'lld', 'debuginfo-tests'])}, | ||
|
|
||
| {'name' : 'clang-x64-windows-msvc-forward-slashes', |
There was a problem hiding this comment.
The consensus in llvm/llvm-project#179865 was that this bot was important enough to run, but not important enough to spend CI resources to run as a pre-merge check.
I have no idea if this is even possible with buildbot, but my ideal scenario would be:
- Run it on a schedule (eg. 1/day)
- If a failure occurs, ideally it could bisect the failure to the failing commit and automatically comment on the commit saying that it broke some postsubmit tests.
What would be the recommended run configuration, and where / how can we configure it?
| script="clang-windows.py", | ||
| depends_on_projects=['llvm', 'clang', 'lld', 'debuginfo-tests'])}, | ||
|
|
||
| {'name' : 'clang-x64-windows-msvc-forward-slashes', |
There was a problem hiding this comment.
I assume we want to start with a staging builder. Is that as simple as adding a suffix "-staging"? Or is there no way to add a staging builder, only a staging worker?
There was a problem hiding this comment.
The configuration is the same between the staging and production buildmasters. There are no naming differences for the builders. It just depends upon which buildmaster you connect your worker to (staging vs production).
This builder is designed to be run to ensure that clang passes tests when -DLLVM_WINDOWS_PREFER_FORWARD_SLASH is enabled.