List of strings; nonconfigurable;
default is []
Tags can be used on any rule. Tags on test and
test_suite
rules are useful for categorizing the tests.
Tags on non-test targets are used to control sandboxed execution of
genrule
s and
Starlark
actions, and for parsing by humans and/or external tools.
Bazel modifies the behavior of its sandboxing code if it finds the following
keywords in the tags
attribute of any test or genrule
target, or the keys of execution_requirements
for any Starlark
action.
no-sandbox
keyword results in the action or test never being
sandboxed; it can still be cached or run remotely - use no-cache
or no-remote
to prevent either or both of those.
no-cache
keyword results in the action or test never being
cached (locally or remotely). Note: for the purposes of this tag, the disk cache
is considered a local cache, whereas the HTTP and gRPC caches are considered
remote. Other caches, such as Skyframe or the persistent action cache, are not
affected.
no-remote-cache
keyword results in the action or test never being
cached remotely (but it may be cached locally; it may also be executed remotely).
Note: for the purposes of this tag, the disk cache is considered a local cache,
whereas the HTTP and gRPC caches are considered remote. Other caches, such as
Skyframe or the persistent action cache, are not affected.
If a combination of local disk cache and remote cache are used (combined cache),
it's treated as a remote cache and disabled entirely unless --incompatible_remote_results_ignore_disk
is set in which case the local components will be used.
no-remote-exec
keyword results in the action or test never being
executed remotely (but it may be cached remotely).
no-remote
keyword prevents the action or test from being executed remotely or
cached remotely. This is equivalent to using both
no-remote-cache
and no-remote-exec
.
no-remote-cache-upload
keyword disables upload part of remote caching of a spawn.
it does not disable remote execution.
local
keyword precludes the action or test from being remotely cached,
remotely executed, or run inside the sandbox.
For genrules and tests, marking the rule with the local = True
attribute has the same effect.
requires-network
keyword allows access to the external
network from inside the sandbox. This tag only has an effect if sandboxing
is enabled.
block-network
keyword blocks access to the external
network from inside the sandbox. In this case, only communication
with localhost is allowed. This tag only has an effect if sandboxing is
enabled.
requires-fakeroot
runs the test or action as uid and gid 0 (i.e., the root
user). This is only supported on Linux. This tag takes precedence over the
--sandbox_fake_username
command-line option.
Tags on tests are generally used to annotate a test's role in your debug and release process. Typically, tags are most useful for C++ and Python tests, which lack any runtime annotation ability. The use of tags and size elements gives flexibility in assembling suites of tests based around codebase check-in policy.
Bazel modifies test running behavior if it finds the following keywords in the
tags
attribute of the test rule:
exclusive
will force the test to be run in the
"exclusive" mode, ensuring that no other tests are running at the
same time. Such tests will be executed in serial fashion after all build
activity and non-exclusive tests have been completed. Remote execution is
disabled for such tests because Bazel doesn't have control over what's
running on a remote machine.
exclusive-if-local
will force the test to be run in the
"exclusive" mode if it is executed locally, but will run the test in parallel if it's
executed remotely.
manual
keyword will exclude the target from expansion of target pattern wildcards
(...
, :*
, :all
, etc.) and test_suite
rules
which do not list the test explicitly when computing the set of top-level targets to build/run
for the build
, test
, and coverage
commands. It does not
affect target wildcard or test suite expansion in other contexts, including the
query
command. Note that manual
does not imply that a target should
not be built/run automatically by continuous build/test systems. For example, it may be
desirable to exclude a target from bazel test ...
because it requires specific
Bazel flags, but still have it included in properly-configured presubmit or continuous test
runs.
external
keyword will force test to be unconditionally
executed (regardless of --cache_test_results
value).