Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pkg_zip and cc_test generate ActionConflictException #814

Open
peakschris opened this issue Jan 25, 2024 · 3 comments
Open

pkg_zip and cc_test generate ActionConflictException #814

peakschris opened this issue Jan 25, 2024 · 3 comments
Labels
P3 An issue that we are not working on but will review quarterly

Comments

@peakschris
Copy link

pkg_zip and cc_test do not seem to work when both targets are provided to a single Bazel invocation. It might seem odd to zip a cc_test, but we have existing downstream systems that we need to send some of our tests to for validation, and it's easiest to collect them in a zip file. The pkg_zip works fine on its own, but fails with an action conflict exception when invoked together with a build of the underlying binary. This issue means that aquery on the root of the repo and other full analysis actions fail.

I have tried pkg_zip 0.9.1 and 0.10.0, both have same issue
I have tried a few GoogleTest versions, all fail
Bazel 7.0.1 and 7.0.0
Both Windows & Linux

A simple MRE is here: https://github.com/peakschris/pkg-zip-of-cc-test

@peakschris
Copy link
Author

>bazel build //image/...

INFO: Analyzed 2 targets (2 packages loaded, 6 targets configured).
INFO: Found 2 targets...
INFO: Elapsed time: 52.360s, Critical Path: 49.56s
INFO: 16 processes: 11 internal, 5 local.
INFO: Build completed successfully, 16 total actions

>bazel build //test:autotest

d:\workdir\bazel-bugs\pkg-zip-of-cc-test>bazel build //test:autotest
INFO: Analyzed target //test:autotest (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
Target //test:autotest up-to-date:
  bazel-bin/test/autotest.zip
INFO: Elapsed time: 68.153s, Critical Path: 64.14s
INFO: 26 processes: 5 internal, 21 local.
INFO: Build completed successfully, 26 total actions

>bazel build //test/... (should succeed)

ERROR: file 'test/_objs/hello-test/hello-test.obj' is generated by these conflicting actions:
Label: //test:hello-test
RuleClass: cc_test rule
JavaActionClass: class com.google.devtools.build.lib.rules.cpp.CppCompileAction
Configuration: 037b71147dce20e29b385bbe5e29ecc7c08187f4871645c5d37280b98e63689c, 6fe48eddc5b9276278a25dc349d4a44501a06143a54c1e29623c2ddde20a6bc6
Mnemonic: CppCompile
Action key: bb74caa43eae930246d82b0fa00f87416815859f77d67e1e060aff5274f4f667
Progress message: Compiling test/hello-test.cc
Action describeKey: Compiling test/hello-test.cc
  Command: C:/apps/MVS174/VC/Tools/MSVC/14.36.32532/bin/HostX64/x64/cl.exe
  Argument: @bazel-out/x64_windows-fastbuild/bin/test/_objs/hello-test/hello-test.obj.params
  (snip)

>bazel aquery //test/... (should succeed)

ERROR: file 'test/_objs/hello-test/hello-test.obj' is generated by these conflicting actions:
Label: //test:hello-test
RuleClass: cc_test rule
JavaActionClass: class com.google.devtools.build.lib.rules.cpp.CppCompileAction
Configuration: 037b71147dce20e29b385bbe5e29ecc7c08187f4871645c5d37280b98e63689c, 6fe48eddc5b9276278a25dc349d4a44501a06143a54c1e29623c2ddde20a6bc6
Mnemonic: CppCompile
Action key: bb74caa43eae930246d82b0fa00f87416815859f77d67e1e060aff5274f4f667
Progress message: Compiling test/hello-test.cc
Action describeKey: Compiling test/hello-test.cc
  Command: C:/apps/MVS174/VC/Tools/MSVC/14.36.32532/bin/HostX64/x64/cl.exe
  Argument: @bazel-out/x64_windows-fastbuild/bin/test/_objs/hello-test/hello-test.obj.params
  Declared include source: external/googletest~1.14.0/googlemock/include/gmock/gmock-actions.h
  (snip)

@aiuto
Copy link
Collaborator

aiuto commented Feb 8, 2024

That's interesting.
My hunch is that this is because you are building hello_test for both the target and exec configurations and they are not quite differentiated enough to get this right. To clarify the last point, //test:autotest is being built for the target configuration, but //test:hello-test must be built for the exec configuration, because that is where it runs.

Is your .bazelrc bringing in other flags, or is this totally clean?

One workaround might be to make hello_test a cc_binary, then wrap it in a test running rule. Another we have used is wrap hello_test with a rule that does a transition to the target configuration and depend on that from autotest.

Overall, this is a complex thing we probably can't fix directly in rules_pkg. It goes into some core Bazel bits. We hit this problem all the time in other contexts where people want to bundle a test and send it to another environment to run later.

@aiuto aiuto added the P3 An issue that we are not working on but will review quarterly label Feb 8, 2024
@peakschris
Copy link
Author

This issue also exists when a cc_test is put in a filegroup. I have renamed the minimal example and opened an issue in bazel build.

https://github.com/peakschris/filegroup-of-cc-test
bazelbuild/bazel#21410

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 An issue that we are not working on but will review quarterly
Projects
None yet
Development

No branches or pull requests

2 participants