bazel: Build 5.0.0-pre.20211011.2 fails with "file is generated by these conflicting actions"
Description of the problem / feature request:
When using 5.0.0-pre.20211011.2, calling a rule with testonly=True fails with the following error (see repro):
bazel build //...
Sandboxfs is activated
Running bazel with args: ['build', '//...']
ERROR: file 'repro/_objs/test/x.test.pic.o' is generated by these conflicting actions:
Label: //repro:test
RuleClass: cc_test rule
Configuration: eb5aa7e35a39550df811eb60154df7436a41dfb63084ca9e51c1a541bf5afff6, ee8d6eaa0d889f4c6823cf490fda5a6abbd816f2da1fb3ea369bdb12bcf6f68a
Mnemonic: CppCompile
Action key: 02da5c72aa15f35128a4e61749fbf1fbb8059850f350c190718a92f0c93c84fe
Progress message: Compiling repro/x.test.cpp
PrimaryInput: File:[/Users/dhavenstein/Desktop/bazel5repro[source]]repro/x.test.cpp
PrimaryOutput: File:[[<execution_root>]bazel-out/darwin-fastbuild/bin]repro/_objs/test/x.test.pic.o
Owner information: ConfiguredTargetKey{label=//repro:test, config=BuildConfigurationValue.Key[eb5aa7e35a39550df811eb60154df7436a41dfb63084ca9e51c1a541bf5afff6]}, ConfiguredTargetKey{label=//repro:test, config=BuildConfigurationValue.Key[ee8d6eaa0d889f4c6823cf490fda5a6abbd816f2da1fb3ea369bdb12bcf6f68a]}
MandatoryInputs: are equal
Outputs: are equal
ERROR: com.google.devtools.build.lib.skyframe.ArtifactConflictFinder$ConflictException: com.google.devtools.build.lib.actions.MutableActionGraph$ActionConflictException: for repro/_objs/test/x.test.pic.o, previous action: action 'Compiling repro/x.test.cpp', attempted action: action 'Compiling repro/x.test.cpp'
Feature requests: what underlying problem are you trying to solve with this feature?
Trying out new Bazel version on existing, large codebase
Bugs: what’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
In an empty dir, create empty WORKSPACE file, and the following files:
cat .bazelversion
5.0.0-pre.20211011.2
cat repro/BUILD.bazel
load("@rules_cc//cc:defs.bzl", "cc_test")
load(":helpers.bzl", "dummy")
cc_test(
name = "test",
srcs = glob([
"*.cpp",
"*.hpp",
]),
)
dummy(name="d",binary=":test", testonly=True)
cat repro/helpers.bzl
def _dummy(ctx):
return [DefaultInfo(files = depset(direct = []))]
dummy = rule(
implementation = _dummy,
attrs = {
"binary" : attr.label(),
}
)
cat repro/x.test.cpp
int main() {
return 0;
}
What operating system are you running Bazel on?
MacOS BigSur
What’s the output of bazel info release
?
release 5.0.0-pre.20211011.2
If bazel info release
returns “development version” or “(@non-git)”, tell us how you built Bazel.
Downloaded from Releases page
What’s the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD
?
Does not apply
Have you found anything relevant by searching the web?
No, found no similar issues reported
Any other information, logs, or outputs that you want to share?
You can reach out to me directly on Slack if I can help out with the repro
About this issue
- Original URL
- State: open
- Created 3 years ago
- Reactions: 1
- Comments: 27 (20 by maintainers)
I was referring to the dummy rule in the original post (https://github.com/bazelbuild/bazel/issues/14294#issue-1057216847). Sorry for the confusion.
Reviewing my older notes on this, there are a few experimental flags that may help here:
--experimental_retain_test_configuration_across_testonly
will make it so test configuration is not dropped for testonly targets. This will likely resolve the correctness issue at the expense of performance (since the domain of testonly can be rather deep under some test rules). This is not on globally because there are bugs in AspectFunction that are potentially triggered by the delayed trimming of the test configuration.--experimental_shareable_cpp_compile_actions
makes c++ actions sharable and thus should avoid the action conflict in this case. I am unsure what the progress of migrating it to default on is.That said, having tests under non-test rules is very abnormal and can usually be replaced by using test_suite, or in the more advanced cases (e.g. where you want to run the test binary as a subpart of a different test) having the test rules directly under another test rule (e.g. in the original example, set
test=True
andexecutable=True
for the dummy rule.