docs preview: bazelbuild/bazel#29475

external/vendor.mdx

@@ -95,7 +95,7 @@ Note that vendoring all dependencies has a few **disadvantages**:
 
 Therefore, consider vendoring for specific targets first.
 
-### Vendor tools for Bazel subcommands {:#vendor-tools-for-subcommands}
+### Vendor tools for Bazel subcommands {#vendor-tools-for-subcommands}
 
 Some Bazel subcommands (such as `bazel mod tidy`) have implicit tool
 dependencies that are not reachable from user build targets, so they are

reference/be/common-definitions.mdx

@@ -81,7 +81,7 @@ rules.
 | `package_metadata` | List of [labels](/concepts/labels); [nonconfigurable](#configurable-attributes); default is the package's `default_package_metadata`  A list of labels that are associated metadata about this target. Typically, the labels are simple rules that return a provider of constant values. Rules and aspects may use these labels to perform some additional analysis on the build graph.  The canonical use case is that of [rules_license](https://github.com/bazelbuild/rules_license). For that use case, `package_metadata` and `default_package_metadata` is used to attach information about a package's licence or version to targets. An aspect applied to a top-level binary can be used to gather those and produce compliance reports. |
 | `restricted_to` | List of [labels](/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The list of environments this target can be built for, *instead* of default-supported environments.  This is part of Bazel's constraint system. See `compatible_with` for details. |
 | `tags` | List of strings; [nonconfigurable](#configurable-attributes); 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](/rules/concepts) 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).  See [Tag Conventions](/reference/test-encyclopedia#tag-conventions) in the Test Encyclopedia for more conventions on tags attached to test targets. |
-| `target_compatible_with` | List of [labels](/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
+| `target_compatible_with` | List of [labels](/concepts/labels); default is `[]`  A list of `constraint_value`s that must be present in the target platform and `config_setting`s that must match the target configuration for this target to be considered *compatible*. This is in addition to any constraints already set by the rule type. If the target platform does not satisfy all listed constraints, or the target configuration does not match all listed config_settings, then the target is considered *incompatible*. Incompatible targets are skipped for building and testing when the target pattern is expanded (e.g. `//...`, `:all`). When explicitly specified on the command line, incompatible targets cause Bazel to print an error and cause a build or test failure.  Targets that transitively depend on incompatible targets are themselves considered incompatible. They are also skipped for building and testing.  An empty list (which is the default) signifies that the target is compatible with all platforms. All rules other than [Workspace Rules](workspace) support this attribute. For some rules this attribute has no effect. For example, specifying `target_compatible_with` for a `cc_toolchain` is not useful. See the [Platforms](/docs/platforms#skipping-incompatible-targets) page for more information about incompatible target skipping. |
 | `testonly` | Boolean; [nonconfigurable](#configurable-attributes); default is `False` except for test and test suite targets  If `True`, only testonly targets (such as tests) can depend on this target.  Equivalently, a rule that is not `testonly` is not allowed to depend on any rule that is `testonly`.  Tests (`*_test` rules) and test suites ([test_suite](/reference/be/general#test_suite) rules) are `testonly` by default.  This attribute is intended to mean that the target should not be contained in binaries that are released to production.  Because testonly is enforced at build time, not run time, and propagates virally through the dependency tree, it should be applied judiciously. For example, stubs and fakes that are useful for unit tests may also be useful for integration tests involving the same binaries that will be released to production, and therefore should probably not be marked testonly. Conversely, rules that are dangerous to even link in, perhaps because they unconditionally override normal behavior, should definitely be marked testonly. |
 | `toolchains` | List of [labels](/concepts/labels); [nonconfigurable](#configurable-attributes); default is `[]`  The set of targets whose [Make variables](/reference/be/make-variables) this target is allowed to access. These targets are either instances of rules that provide `TemplateVariableInfo` or special targets for toolchain types built into Bazel. These include:  * `@bazel_tools//tools/cpp:toolchain_type`* `@rules_java//toolchains:current_java_runtime`   Note that this is distinct from the concept of [toolchain resolution](/docs/toolchains#toolchain-resolution) that is used by rule implementations for platform-dependent configuration. You cannot use this attribute to determine which specific `cc_toolchain` or `java_toolchain` a target will use. |
 | `visibility` | List of [labels](/concepts/labels); [nonconfigurable](#configurable-attributes); default varies  The `visibility` attribute controls whether the target can be depended on by targets in other locations. See the documentation for [visibility](/concepts/visibility).  For targets declared directly in a BUILD file or in legacy macros called from a BUILD file, the default value is the package's `default_visibility` if specified, or else `["//visibility:private"]`. For targets declared in one or more symbolic macros, the default value is always just `["//visibility:private"]` (which makes it useable only within the package containing the macro's code). |