<p>
  <code>List of arbitrary text tags.  Tags may be any valid string; default is
  the empty list.</code>
</p>

<p>
  <i>Tags</i> can be used on any rule. <i>Tags</i> on test and
  <code>test_suite</code> rules are useful for categorizing the tests.
  <i>Tags</i> on non-test rules are used to control sandboxed execution of
  <code>genrule</code>s and

<a href="/versions/{{ site.version }}/skylark/index.html">Skylark</a>
  actions, and for parsing by humans and/or external tools.
</p>

<p>
  Bazel modifies the behavior of its sandboxing code if it finds the following
  keywords in the <code>tags</code> attribute of any test rule or
  <code>genrule</code>, or the keys of <code>execution_requirements</code> for
  any Skylark action.
</p>

<ul>
  <li><code>local</code> keyword results in the action or test never being
    run remotely or inside the
    <a href="../user-manual.html#sandboxing">sandbox</a>.
    For genrules and tests, marking the rule with the <code>local = 1</code>
    attribute has the same effect.
  </li>

  <li><code>block-network</code> keyword blocks access to the external
    network from inside the sandbox. In this case, only communication
    with localhost is allowed.
  </li>

  <li><code>requires-fakeroot</code> 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
    <code class='flag'>--sandbox_fake_username</code> command-line option.
  </li>
</ul>

<p>
  <i>Tags</i> 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.
</p>

<p>
  Bazel modifies test running behavior if it finds the following keywords in the
  <code>tags</code> attribute of the test rule:
</p>

<ul>
  <li><code>exclusive</code> keyword will force the test to be run in the
    &quot;exclusive&quot; 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. They will also always
    run locally and thus without sandboxing.
  </li>

  <li><code>manual</code> keyword will force the test target to not be included in target pattern
    wildcards (<code>...</code>, <code>:*</code>, <code>:all</code>, etc); the test target will be
    neither built nor run. It will also be ignored by the <code>test_suite</code> rules that do not
    mention this test explicitly. The only way to build or run such a test is to specify it via an
    explicit target pattern on the command line.
  </li>

  <li><code>external</code> keyword will force test to be unconditionally
    executed (regardless of <code class='flag'>--cache_test_results</code>
    value).
  </li>
</ul>