The worker-key-mnemonic execution info allows sharing the same worker across multiple actions using different mnemonics by overriding the mnemonic that identifies the worker. This allows avoiding spawning multiple, usually resource intensive, workers for different actions that use the same worker executable. However, this does not work with --worker_extra_flag=<mnemonic>=<flag> since the mnemonic in this syntax is not the worker mnemonic, but the action mnemonic. This results in spawning multiple worker, nullifying the effect of the execution info, unless the same flags are specified for all the mnemonic using the worker.
Which category does this issue belong to?
Rules API
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Description of the bug:
The
worker-key-mnemonic
execution info allows sharing the same worker across multiple actions using different mnemonics by overriding the mnemonic that identifies the worker. This allows avoiding spawning multiple, usually resource intensive, workers for different actions that use the same worker executable. However, this does not work with--worker_extra_flag=<mnemonic>=<flag>
since the mnemonic in this syntax is not the worker mnemonic, but the action mnemonic. This results in spawning multiple worker, nullifying the effect of the execution info, unless the same flags are specified for all the mnemonic using the worker.Which category does this issue belong to?
Rules API
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Create a rule with two actions:
The build a target of that rule passing
--worker_extra_flag=Foo=--bar
and see two workers spawned.Which operating system are you running Bazel on?
Ubuntu
What is the output of
bazel info release
?release 6.5.0
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
?No response
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