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.
Related
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.
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.
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.
I managed to install Google Test on Jenkins.
I use cmake to build the test executable and everything works fine.
The stupid question I have now is:
How do I automatically let Jenkins run google test?
Do I have to write a shell script for this or is there a better way?
I know that one could run it in ant but since I use cmake I doubt that this is the right way to go.
There's no builtin or pluggable "Googletest automation" for Jenkins.
You've built the test executable with CMake in a build step.
Execute the test executable in a subsequent build step
with xml test reporting enabled
and configure the build to archive or otherwise publish the test reports.
I have a sbt project with 4 modules: module-a, module-b, module-c, module-d.
Each module can be packaged as a WAR. I want to set up a deployment on Jenkins that would build only one of the 4 modules and deploy it to a container.
In detail, I want to have 4 Jenkins jobs - job-a, job-b, job-c, job-d, each building only the defined module (a to d).
For now, I am using clean update test package as the command for the Jenkins sbt build, but this results in packaging all 4 modules that is not necessary.
I already tried project -module-a clean update test package but with no luck.
You may also like to execute project-scoped clean and test tasks as follows:
sbt module-a/clean module-a/test
The solution is slightly shorter and clearer as to what project the following commands apply to.
You don't need to execute update task since it's implicitly executed by test as described in inspect tree test.
There's a way to make it cleaner with an alias. Use the following in the build.sbt:
addCommandAlias("jenkinsJob4ModuleA", "; module-a/clean; module-a/test")
With the alias, execute jenkinsJob4ModuleA to have the same effect as the above solution.
Quote the argument to project, i.e. project module-a, and don't use a dash before the name of the submodule.
The entire command line for the Jenkins job would than be as follows:
./sbt "project module-a" clean update test