We're considering migrating to Bazel from Make. To make the transition easier I would like to have bazel test (no flags / options) run the current directory's tests, if any.
So instead of bazel test my_tests bazel test would find the current directory's BUILD file, find any *_test rules and run those.
If you want to do exactly as you said then you can use your own script.
When you run “bazel” it actually looks to see if there is a script named “bazel” under tools directory of the current workspace. So if you have an executable under “$workspace/tools/bazel” bazel will run that instead of the bazel binary itself.
This means you can write a script that checks if the only argument is “test” and if so calls “bazel-real test :all”
It can also check the exit code to see if there were no tests (it’s a specific error code) and return 0 instead
You can use the all target pattern to match all targets in the current package: bazel test :all
You can read more about it here: https://docs.bazel.build/versions/master/user-manual.html#target-patterns
Note however that if there are no test targets in the current package, bazel will give an error: "ERROR: No test targets were found, yet testing was requested.". In this case bazel will give an exit code of 4: https://docs.bazel.build/versions/master/user-manual.html#what-exit-code-will-i-get
I recommend creating a alias called bazel-test to bazel test :all.
Related
given a bazel command, for example bazel build //..., is it possible to see what build command this expands to based on the bazelrc(s)?
bazelrcs are great to set default flags, like the default platform to build for setting some variables based on profiles.
They also allow for nested bazelrcs, that you can import and try-import leading to a rather complex expansion of bazel commands via bazelrcs.
To verify that the bazelrcs did indeed configure the correct things and did not override some flags accidentally, I would love to see the output of what bazel would expand a bazel command to.
Is that possible?
I tried setting --logging=0 and --logging=6 with bazel 5.3.0 but see no such output.
You can run your build using the --explain flag.
Something like
bazel build --explain explain.log //...
should produce a file explain.log where the first line contains the expanded flags.
From my tests, it doesn't appear that bazel run runs in a sandbox. For example, I ran bazel run //:some_target --spawn_strategy=darwin-sandbox --sandbox_debug, and it didn't generate a new directory in <outputBase>/sandbox/darwin-sandbox.
Am I correct that bazel run doesn't use sandboxing? If so, why not?
bazel run will build the target you pass with sandboxing and caching the same way as bazel build, and then it will run it outside the sandbox. That's the whole point of bazel run.
If you want to run a command inside the sandbox, write a genrule and then bazel build the genrule target.
I have added an annotation processor as a java_plugin and have added this into the plugins section of my java_library rule. I was wondering what are the bazel options to step through the annotation processor code and the javac compiler's code?
One way to do this is to run bazel build with --subcommands. Bazel will then print out all the commands it executes during a build. You can then find the javac invocation you're interested in, copy the command line (including the cd part so you're in the correct directory), modify the command line to include the debugging options, and run it manually. Then you can debug it like you would any java program.
One thing to note is that bazel will print only the commands that it actually runs in that build, so if the action you're interested in is already up-to-date, you may have to delete one of its outputs (e.g. the jar output of that library) to get bazel to re-run the action.
I am trying to follow the instructions for contributors here:
https://bazel.build/contributing.html
I have a successful build off of master (i.e. bazel build //src:bazel), but the doc suggests also "you might want to build the various tools Bazel uses." I am trying to do that, for example:
cd src/java_tools/singlejar
bazel build //...
but it fails with:
ERROR: /Users/.../bazel/third_party/protobuf/3.2.0/BUILD:621:1: no such target '//external:gtest': target 'gtest' not declared in package 'external' defined by /Users/plaird/scone/public/bazel/WORKSPACE and referenced by '//third_party/protobuf/3.2.0:test_plugin'.
Do I need to build gtest locally, and then add it to the WORKSPACE file?
bazel build //..., no matter where you invoke it, will build everything in the project. It looks like what you probably want is bazel build //src/java_tools/singlejar/..., which will build all targets under that directory.
In general, though, you probably don't need to compile singlejar separately. I've been working on Bazel for several years and 99% of the time you don't have to build the tools separately.
In terms of the error you're getting, it would be nice if we could get //... building, but it hasn't been a huge priority. The protobuf code build is weird and I don't recommend trying to debug it, just jump into whatever you want to actually work on.
running bazel build //... \
--aspects some-aspect.bzl%some_aspect \
--output_groups=some_new_output,default
does not create test jars outputs.
on the other hand running bazel test does create the test jar outputs:
bazel test //... \
--aspects some-aspect.bzl%some_aspect \
--output_groups=some_new_output,default
How come?
This question was updated to reflect use of aspects:
The original question:
running bazel build //... does not add test code to output jar.
on the other hand bazel test //... builds the test code but also
runs it.
Is there a way in bazel to build the test code without running the
tests?
I had a mistake in the values I gave the --output_groups flag.
It should have been --output_groups=+some_new_output,+default
The default can even be omitted:
--output_groups=+some_new_output
This flag is not documented at all. There is an open issue on this in bazel github repo.
You may be looking for --build_tests_only.