Build & Test
Testing
The test
task runs bazel test
.
By default, the test
task also builds all build-able targets.
The simplest configuration:
tasks:
- test:
This runs all tests in the workspace, for example bazel test //...
.
You can specify target with the targets
attribute, which is a list of patterns.
Prefix the pattern with -
to exclude targets.
tasks:
- test:
targets:
# All targets in project A
- //projectA/...
# But excluding this subpackage
- -//projectA/excluded:all
You can also specify additional Bazel flags for the task.
Enabling coverage
Workflows doesn't run bazel coverage
due to historical bugs with invalidating the analysis cache.
Instead, bazel test
runs with specific flags that have equivalent behavior.
To enable coverage on a test
task, add coverage: true
to the task configuration:
tasks:
- test:
coverage: true
Building
A build
task runs bazel build
.
By default, the test
task also builds all build-able targets,
so a typical configuration file does not use the build
task.
There are a few cases where a build
task is useful:
- When the
--build_tests_only
flag is passed to Bazel, then thetest
task does not build targets which aren't a dependency of any tests. - Some test targets may be known to be broken. You can use a
build
task to only build the tests, but not run them.
A simple configuration looks like:
tasks:
- build:
This builds all targets in the workspace, for example bazel build //...
.
You can specify target with the targets
attribute, which is a list of patterns.
tasks:
- build:
targets:
# All targets in project A
- //projectA/...
# But excluding this subpackage
- -//projectA/excluded:all
Specifying Bazel flags
You should generally check Bazel flags into a .bazelrc
file.
Workflows looks for a .aspect/workflows/bazelrc
file, and if it exists then Workflows passes
--bazelrc=.aspect/workflows/bazelrc
to every invocation of Bazel.
You can also place flags in the configuration file, at the top-level or under a task:
bazel:
flags:
# Allow any actions to see the value of $HOME
- --action_env=HOME
tasks:
- test:
bazel:
flags:
# Allow any actions to see the value of $HOME
- --action_env=HOME
# Allow tests to fetch private container images from Docker Hub
- --test_env=DOCKER_USERNAME
- --test_env=DOCKER_PASSWORD
Task level flags are not merged with top-level flags. Instead, Bazel flags specified for a task overrides the list of Bazel flags set at the top-level level.
bes_backend
Bazel doesn't support multiple bes_backend
s and Workflows takes the default spot. You can set the value to another backend to let the Aspect CLI (running the Workflows runners) know that it should forward the BES onto that endpoint.
For an individual task:
tasks:
- test:
bazel:
flags:
- --bes_backend=grpcs://<url>
Or on the top level to apply to all tasks:
bazel:
flags:
- --bes_backend=grpcs://<url>
tasks:
Specifying Bazel start-up flags
You should generally check startup flags into a .bazelrc
file, however, some startup flags such
as --noworkspace_rc
may only be specified as command line flags.
As with regular flags, you can also place startup flags in the configuration file, at the top-level or under a task:
bazel:
startup_flags:
# Ignore the WORKSPACE .bazelrc file on CI
- --noworkspace_rc
tasks:
- test:
bazel:
startup_flags:
# Ignore the WORKSPACE .bazelrc file on CI
- --noworkspace_rc
# Increase maximum JVM heap size for the bazel server
- --host_jvm_args=-Xmx12g
Task level startup flags are not merged with top-level startup flags. Instead, Bazel startup flags specified for a task overrides the list of Bazel startup flags set at the top-level level.
API doc
You can find the exhaustive list of attributes for the build
task in
build, and for the test
task in
test.