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
Is your feature request related to a problem? Please describe.
We have some heavy integration tests that require more than 1 cpu core to be available to run reliably.
I understand Bazel has a similar feature but I have no experience with it
Tests are granted at least one CPU core. Others may be available but this is not guaranteed. Other performance aspects of this core are not specified. You can increase the reservation to a higher number of CPU cores by adding the tag "cpu:n" (where n is a positive number) to a test rule. If a machine has less total CPU cores than requested, Bazel will still run the test. If a test uses sharding, each individual shard will reserve the number of CPU cores specified here.
Describe the solution you'd like
I'd like to express this requirement in the target directly (or inferred in our heuristic in our plugin). Ultimately I think this could be treated similarly to concurrency_available but it needs to be a constant value instead of a suggestion.
Describe alternatives you've considered
As a work around we need to manually include/exclude certain targets or use --process-parallelism but that has the negative side effect of modifying the entire run, not just the resource heavy steps
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
We have some heavy integration tests that require more than 1 cpu core to be available to run reliably.
I understand Bazel has a similar feature but I have no experience with it
Similar conversations in slack
https://pantsbuild.slack.com/archives/C046T6T9U/p1651770597838669
Related Issues
#15482 (comment)
Describe the solution you'd like
I'd like to express this requirement in the target directly (or inferred in our heuristic in our plugin). Ultimately I think this could be treated similarly to
concurrency_available
but it needs to be a constant value instead of a suggestion.Describe alternatives you've considered
As a work around we need to manually include/exclude certain targets or use
--process-parallelism
but that has the negative side effect of modifying the entire run, not just the resource heavy stepsThe text was updated successfully, but these errors were encountered: