You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When developers compile on CPU machines, where the host platform does not have the //:some_gpu_requirement, but a register remote execution platform does have the constraint, I believe dynamic execution ignores this difference, and still attempts to race the test locally, even though it doesn't match the requirements.
I can probably workaround this by disabling dynamic execution for the TestRunner mnemonic, but I'm still surprised by this behavior.
If I aquery the test I can see the execution platform is set correctly, but then you can see it still runs locally with --debug_spawn_scheduler
INFO: Analyzed target //Support/test:system-info/system-info.mlir.test (0 packages loaded, 12 targets and 2 aspects configured).
INFO: local branch of Support/test/system-info/system-info.mlir.test/test.log finished and was not cancelled
INFO: CancellationException of remote branch of Support/test/system-info/system-info.mlir.test/test.log, returning null
INFO: local branch of Support/test/system-info/system-info.mlir.test/test.log finished and was not cancelled
INFO: CancellationException of remote branch of Support/test/system-info/system-info.mlir.test/test.log, returning null
Which category does this issue belong to?
No response
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Description of the bug:
We have a test target like this:
When developers compile on CPU machines, where the host platform does not have the
//:some_gpu_requirement
, but a register remote execution platform does have the constraint, I believe dynamic execution ignores this difference, and still attempts to race the test locally, even though it doesn't match the requirements.I can probably workaround this by disabling dynamic execution for the
TestRunner
mnemonic, but I'm still surprised by this behavior.If I
aquery
the test I can see the execution platform is set correctly, but then you can see it still runs locally with--debug_spawn_scheduler
Which category does this issue belong to?
No response
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
No response
Which operating system are you running Bazel on?
Linux
What is the output of
bazel info release
?b4c611b
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse HEAD
?If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: