From 649ac59560022bb0877e266a2eb75acf07915ee0 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Wed, 12 Aug 2026 21:23:01 +0000 Subject: [PATCH] chore: update documentation from upstream Bazel repo [skip ci] Synchronized pre-converted MDX files from upstream Bazel repository. --- about/faq.mdx | 2 +- configure/coverage.mdx | 32 +++++++++++++- contribute/codebase.mdx | 42 +++++++++--------- contribute/docs.mdx | 41 +++++++++++++---- contribute/statemachine-guide.mdx | 2 +- docs/android-ndk.mdx | 2 +- docs/sandboxing.mdx | 7 +-- docs/user-manual.mdx | 44 +++++++++---------- extending/config.mdx | 28 ------------ extending/rules.mdx | 2 +- install/compile-source.mdx | 2 +- install/ubuntu.mdx | 2 +- migrate/xcode.mdx | 2 +- navigation.json | 8 ---- navigation/HEAD.en.json | 7 +++ query/cquery.mdx | 2 +- reference/test-encyclopedia.mdx | 2 +- release/index.mdx | 2 +- remote/output-directories.mdx | 2 +- remote/persistent.mdx | 11 +---- remote/sandbox.mdx | 2 +- rules/language.mdx | 3 +- rules/rules-tutorial.mdx | 2 +- rules/testing.mdx | 2 +- run/build.mdx | 1 + run/scripts.mdx | 3 +- upstream | 2 +- versions/7.6.1/install/ubuntu.mdx | 2 +- .../7.6.1/reference/test-encyclopedia.mdx | 2 +- versions/7.7.1/install/ubuntu.mdx | 2 +- .../7.7.1/reference/test-encyclopedia.mdx | 2 +- versions/8.0.1/install/ubuntu.mdx | 2 +- .../8.0.1/reference/test-encyclopedia.mdx | 2 +- versions/8.1.1/install/ubuntu.mdx | 2 +- .../8.1.1/reference/test-encyclopedia.mdx | 2 +- versions/8.2.1/install/ubuntu.mdx | 2 +- .../8.2.1/reference/test-encyclopedia.mdx | 2 +- versions/8.3.1/install/ubuntu.mdx | 2 +- .../8.3.1/reference/test-encyclopedia.mdx | 2 +- versions/8.4.2/install/ubuntu.mdx | 2 +- .../8.4.2/reference/test-encyclopedia.mdx | 2 +- versions/8.5.1/install/ubuntu.mdx | 2 +- .../8.5.1/reference/test-encyclopedia.mdx | 2 +- .../8.6.0/reference/test-encyclopedia.mdx | 2 +- versions/9.0.0/install/ubuntu.mdx | 2 +- .../9.0.0/reference/test-encyclopedia.mdx | 2 +- versions/9.1.0/install/ubuntu.mdx | 2 +- .../9.1.0/reference/test-encyclopedia.mdx | 2 +- 48 files changed, 156 insertions(+), 143 deletions(-) diff --git a/about/faq.mdx b/about/faq.mdx index 03fb0c117..fa5a4d0c3 100644 --- a/about/faq.mdx +++ b/about/faq.mdx @@ -155,7 +155,7 @@ For other IDEs, check out the [blog post](https://blog.bazel.build/2016/06/10/id Bazel returns a non-zero exit code if the build or test invocation fails, and this should be enough for basic CI integration. Since Bazel does not need clean builds for correctness, the CI system should not be configured to clean before starting a build/test run. -Further details on exit codes are in the [Scripts guide](/run/scripts#exit-codes). +Further details on exit codes are in the [User Manual](/docs/user-manual). ## Can I use Bazel for my INSERT LANGUAGE HERE project? diff --git a/configure/coverage.mdx b/configure/coverage.mdx index 4a4462181..1eacadfc1 100644 --- a/configure/coverage.mdx +++ b/configure/coverage.mdx @@ -13,7 +13,9 @@ This page documents the general process for creating and viewing coverage reports, and also features some language-specific notes for languages whose configuration is well-known. It is best read by first reading [the general section](#creating-a-coverage-report), and then -reading about the requirements for a specific language. +reading about the requirements for a specific language. Note also the +[remote execution section](#remote-execution), which requires some +additional considerations. While a lot of customization is possible, this document focuses on producing and consuming [`lcov`][lcov] reports, which is currently the @@ -83,6 +85,32 @@ To view the result, simply open the `index.html` file produced in the For further help and information around the `genhtml` tool, or the `lcov` coverage format, see [the lcov project][lcov]. +## Remote execution {#remote-execution} + +Running with remote test execution currently has a few caveats: + +- The report combination action cannot yet run remotely. This is + because Bazel does not consider the coverage output files as part of + its graph (see [this issue][remote_report_issue]), and can therefore + not correctly treat them as inputs to the combination action. To + work around this, use `--strategy=CoverageReport=local`. + - Note: It may be necessary to specify something like + `--strategy=CoverageReport=local,remote` instead, if Bazel is set + up to try `local,remote`, due to how Bazel resolves strategies. +- `--remote_download_minimal` and similar flags can also not be used + as a consequence of the former. +- Bazel will currently fail to create coverage information if tests + have been cached previously. To work around this, + `--nocache_test_results` can be set specifically for coverage runs, + although this of course incurs a heavy cost in terms of test times. +- `--experimental_split_coverage_postprocessing` and + `--experimental_fetch_all_coverage_outputs` + - Usually coverage is run as part of the test action, and so by + default, we don't get all coverage back as outputs of the remote + execution by default. These flags override the default and obtain + the coverage data. See [this issue][split_coverage_issue] for more + details. + ## Language-specific configuration ### C++ @@ -116,3 +144,5 @@ for additional steps needed to enable coverage support in Python. [lcov]: https://github.com/linux-test-project/lcov [bazel_toolchains]: https://github.com/bazelbuild/bazel-toolchains +[remote_report_issue]: https://github.com/bazelbuild/bazel/issues/4685 +[split_coverage_issue]: https://github.com/bazelbuild/bazel/issues/4685 diff --git a/contribute/codebase.mdx b/contribute/codebase.mdx index 73f310e8c..6c63f7e04 100644 --- a/contribute/codebase.mdx +++ b/contribute/codebase.mdx @@ -260,7 +260,7 @@ on Windows, where file names are case-insensitive. Packages are independent of each other: changes to the `BUILD` file of a package cannot cause other packages to change. The addition or removal of `BUILD` files -_can_ change other packages, since recursive globs stop at package boundaries +_can _change other packages, since recursive globs stop at package boundaries and thus the presence of a `BUILD` file stops the recursion. The evaluation of a `BUILD` file is called "package loading". It's implemented @@ -305,7 +305,7 @@ Packages are composed of targets, which have the following types: Bazel parlance, we call them _artifacts_ (discussed elsewhere). Not all files created during the build are targets; it's common for an output of Bazel not to have an associated label. -2. **Rules:** these describe steps to derive their outputs from their inputs. They +2. **Rules:** these describe steps to derive its outputs from its inputs. They are generally associated with a programming language (such as `cc_library`, `java_library` or `py_library`), but there are some language-agnostic ones (such as `genrule` or `filegroup`) @@ -353,7 +353,7 @@ of that type. The evaluation framework underlying Bazel is called Skyframe. Its model is that everything that needs to be built during a build is organized into a directed -acyclic graph with edges pointing from any piece of data to its dependencies, +acyclic graph with edges pointing from any pieces of data to its dependencies, that is, other pieces of data that need to be known to construct it. The nodes in the graph are called `SkyValue`s and their names are called @@ -398,7 +398,7 @@ around this issue by: limit the number of restarts. 2. Breaking up a `SkyValue` into separate pieces computed by different `SkyFunction`s, so that they can be computed and cached independently. This - should be done strategically, since it has the potential to increase memory + should be done strategically, since it has the potential to increases memory usage. 3. Storing state between restarts, either using `SkyFunction.Environment.getState()`, or keeping an ad hoc static cache @@ -414,7 +414,7 @@ around this issue by: [statemachine_example]: https://developers.google.com/devsite/reference/markdown/links#reference_links -Fundamentally, Bazel needs these types of workarounds because hundreds of +Fundamentally, Bazel need these types of workarounds because hundreds of thousands of in-flight Skyframe nodes is common, and Java's support of lightweight threads [does not outperform][virtual_threads] the `StateMachine` implementation as of 2023. @@ -526,9 +526,9 @@ affects test targets (we have plans to "trim" configurations so that this is not the case, but it's not ready yet). When a rule implementation needs part of the configuration, it needs to declare -it in its definition using `RuleClass.Builder.requiresConfigurationFragments()`. -This is both to avoid mistakes (such as Python rules using the Java fragment) and -to facilitate configuration trimming so that if Python options change, C++ +it in its definition using `RuleClass.Builder.requiresConfigurationFragments()` +. This is both to avoid mistakes (such as Python rules using the Java fragment) and +to facilitate configuration trimming so that such as if Python options change, C++ targets don't need to be re-analyzed. The configuration of a rule is not necessarily the same as that of its "parent" @@ -559,7 +559,7 @@ Configuration transitions can also be implemented in Starlark (documentation ### Transitive info providers {#transitive-info-providers} -Transitive info providers are a way (and the _only_ way) for configured targets +Transitive info providers are a way (and the _only _way) for configured targets to learn things about other configured targets that they depend on, and the only way to tell things about themselves to other configured targets that depend on them. The reason why "transitive" is in their name is that this is usually some @@ -713,13 +713,13 @@ The concept of _toolchain_ comes from the fact that depending on what platforms the build is running on and what platforms are targeted, one may need to use different compilers; for example, a particular C++ toolchain may run on a specific OS and be able to target some other OSes. Bazel must determine the C++ -compiler that is used based on the set execution and target platforms +compiler that is used based on the set execution and target platform (documentation for toolchains [here](/extending/toolchains)). In order to do this, toolchains are annotated with the set of execution and target platform constraints they support. In order to do this, the definition of -a toolchain is split into two parts: +a toolchain are split into two parts: 1. A `toolchain()` rule that describes the set of execution and target constraints a toolchain supports and tells what kind (such as C++ or Java) of @@ -895,7 +895,7 @@ In order to get around this problem, we came up with the concept of a `NestedSet`. It's a data structure that is composed of other `NestedSet` instances and some members of its own, thereby forming a directed acyclic graph of sets. They are immutable and their members can be iterated over. We define -multiple iteration orders (`NestedSet.Order`): preorder, postorder, topological +multiple iteration order (`NestedSet.Order`): preorder, postorder, topological (a node always comes after its ancestors) and "don't care, but it should be the same each time". @@ -1062,7 +1062,7 @@ the set of inputs of an action come in two forms: * An action may discover new inputs before its execution or decide that some of its inputs are not actually necessary. The canonical example is C++, where it's better to make an educated guess about what header files a C++ - file uses from its transitive closure so that we don't need to send every + file uses from its transitive closure so that we don't heed to send every file to remote executors; therefore, we have an option not to register every header file as an "input", but scan the source file for transitively included headers and only mark those header files as inputs that are @@ -1147,7 +1147,7 @@ More information about strategies (or action contexts!): Bazel _can_ run many actions in parallel. The number of local actions that _should_ be run in parallel differs from action to action: the more resources an -action requires, the fewer instances should be running at the same time to avoid +action requires, the less instances should be running at the same time to avoid overloading the local machine. This is implemented in the class `ResourceManager`: each action has to be @@ -1289,7 +1289,7 @@ execution so that outputs of different tests are not interspersed. This is implemented in the aptly-named `StreamedTestOutput` class and works by polling changes to the `test.log` file of the test in question and dumping new -bytes to the terminal where Bazel runs. +bytes to the terminal where Bazel rules. Results of the executed tests are available on the event bus by observing various events (such as `TestAttempt`, `TestResult` or `TestingCompleteEvent`). @@ -1377,7 +1377,7 @@ are provided: * `bazel aquery` is used to investigate the action graph Each of these is implemented by subclassing `AbstractBlazeQueryEnvironment`. -Additional query functions can be done by subclassing `QueryFunction` +Additional additional query functions can be done by subclassing `QueryFunction` . In order to allow streaming query results, instead of collecting them to some data structure, a `query2.engine.Callback` is passed to `QueryFunction`, which calls it for results it wants to return. @@ -1387,7 +1387,7 @@ classes, XML, protobuf and so on. These are implemented as subclasses of `OutputFormatter`. A subtle requirement of some query output formats (proto, definitely) is that -Bazel needs to emit _all_ the information that package loading provides so that +Bazel needs to emit _all _the information that package loading provides so that one can diff the output and determine whether a particular target has changed. As a consequence, attribute values need to be serializable, which is why there are only so few attribute types without any attributes having complex Starlark @@ -1523,7 +1523,7 @@ starting `@guava//` and expect that to mean different versions of it. Therefore, Bazel allows one to re-map external repository labels so that the string `@guava//` can refer to one Guava repository (such as `@guava1//`) in the -repository of one binary and another Guava repository (such as `@guava2//`) in the +repository of one binary and another Guava repository (such as `@guava2//`) the repository of the other. Alternatively, this can also be used to **join** diamonds. If a repository @@ -1591,7 +1591,7 @@ to replay information to the UI caused by various kinds of cached processing, for example, the warnings emitted by a cached configured target. Some `EventHandler`s also allow posting events that eventually find their way to -the event bus (regular `Event`s do _not_ appear there). These are +the event bus (regular `Event`s do _not _appear there). These are implementations of `ExtendedEventHandler` and their main use is to replay cached `EventBus` events. These `EventBus` events all implement `Postable`, but not everything that is posted to `EventBus` necessarily implements this interface; @@ -1616,11 +1616,11 @@ Bazel is fast. Bazel is also slow, because builds tend to grow until just the edge of what's bearable. For this reason, Bazel includes a profiler which can be used to profile builds and Bazel itself. It's implemented in a class that's aptly named `Profiler`. It's turned on by default, although it records only -abridged data so that its overhead is tolerable; the command line +abridged data so that its overhead is tolerable; The command line `--record_full_profiler_data` makes it record everything it can. It emits a profile in the Chrome profiler format; it's best viewed in Chrome. -Its data model is that of task stacks: one can start tasks and end tasks and +It's data model is that of task stacks: one can start tasks and end tasks and they are supposed to be neatly nested within each other. Each Java thread gets its own task stack. **TODO:** How does this work with actions and continuation-passing style? diff --git a/contribute/docs.mdx b/contribute/docs.mdx index 55f8f1bb0..cc240cc48 100644 --- a/contribute/docs.mdx +++ b/contribute/docs.mdx @@ -2,19 +2,42 @@ title: 'Contribute to Bazel documentation' --- -Thank you for contributing to Bazel's documentation! -## How docs work -Bazel documentation lives in two repositories: +Thank you for contributing to Bazel's documentation! There are a few ways to +help create better docs for our community. -- [`bazelbuild/bazel`](https://github.com/bazelbuild/bazel) — all doc content in the `docs/` folder. This is where you make changes. -- [`bazel-contrib/bazel-docs`](https://github.com/bazel-contrib/bazel-docs) — the hosting and navigation layer (Mintlify config, sidebar, PR previews). +## Documentation types -Content changes always go to `bazelbuild/bazel`. Navigation changes go to `bazel-contrib/bazel-docs`. +This site includes a few types of content. -## Contributing + - *Narrative documentation*, which is written by technical writers and + engineers. Most of this site is narrative documentation that covers + conceptual and task-based guides. + - *Reference documentation*, which is generated documentation from code comments. + You can't make changes to the reference doc pages directly, but instead need + to change their source. -- **Make a change or add a page** — see [Docs contribution workflow](/contribute/docs-contribution-workflow) for step-by-step instructions, from a quick typo fix to adding a new page. -- **Update the sidebar navigation** — see [Update the docs navigation](/contribute/docs-navigation) for instructions on adding your new page to the left-hand nav in `bazel-contrib/bazel-docs`. +## Documentation infrastructure +Bazel documentation is served from Google and the source files are mirrored in +Bazel's GitHub repository. You can make changes to the source files in GitHub. +If approved, you can merge the changes and a Bazel maintainer will update the +website source to publish your updates. + + +## Small changes + +You can approach small changes, such as fixing errors or typos, in a couple of +ways. + + - **Pull request**. You can create a pull request in GitHub with the + [web-based editor](https://docs.github.com/repositories/working-with-files/managing-files/editing-files) or on a branch. + - **Bug**. You can file a bug with details and suggested changes and the Bazel + documentation owners will make the update. + +## Large changes + +If you want to make substantial changes to existing documentation or propose +new documentation, you can either create a pull request or start with a Google +doc and contact the Bazel Owners to collaborate. diff --git a/contribute/statemachine-guide.mdx b/contribute/statemachine-guide.mdx index 832c75490..4db66dfaf 100644 --- a/contribute/statemachine-guide.mdx +++ b/contribute/statemachine-guide.mdx @@ -781,7 +781,7 @@ There's a couple of examples of error handling already in [`Tasks.lookUp` callba callbacks as values. Such callbacks often have exclusive-or semantics, with exactly one of a value or error being passed. -The next section describes a subtle, but important interaction with Skyframe +The next section describes a a subtle, but important interaction with Skyframe error handling. #### Error bubbling (--nokeep\_going) {#error-bubbling} diff --git a/docs/android-ndk.mdx b/docs/android-ndk.mdx index ff57bbae9..abd76409a 100644 --- a/docs/android-ndk.mdx +++ b/docs/android-ndk.mdx @@ -308,7 +308,7 @@ bazel build //my/cc/jni:target \ --platforms=//my/platforms:x86_64 ``` -This approach affects the entire build tree. +With this approach, the entire build tree is affected. Note: All of the targets on the command line must be compatible with building for Android when specifying these flags, which may make it difficult to diff --git a/docs/sandboxing.mdx b/docs/sandboxing.mdx index 247813235..aaadcd799 100644 --- a/docs/sandboxing.mdx +++ b/docs/sandboxing.mdx @@ -54,12 +54,7 @@ You can choose which kind of sandboxing to use, if any, with the strategy makes Bazel pick one of the sandbox implementations listed below, preferring an OS-specific sandbox to the less hermetic generic one. [Persistent workers](/remote/persistent) run in a generic sandbox if you pass -the `--worker_sandboxing` flag. In addition to the plain boolean form, the flag -can be scoped to a specific worker-key mnemonic with -`--worker_sandboxing==` (for example -`--worker_sandboxing --worker_sandboxing=Javac=no` to sandbox all singleplex -workers except `Javac`; a later plain boolean value applies to all mnemonics -again). +the `--worker_sandboxing` flag. The `local` (a.k.a. `standalone`) strategy does not do any kind of sandboxing. It simply executes the action's command line with the working directory set to diff --git a/docs/user-manual.mdx b/docs/user-manual.mdx index a4773339a..e901366a4 100644 --- a/docs/user-manual.mdx +++ b/docs/user-manual.mdx @@ -1081,10 +1081,9 @@ If `--explain` is not enabled, then #### `--profile=file` {#profile} This option, which takes a filename argument, causes Bazel to write -profiling data into a file. The build profile can be useful in understanding -where Bazel's `build` command is spending its time. See -[JSON trace profile](/advanced/performance/json-trace-profile) for profile -format and tooling details. +profiling data into a file. The data then can be analyzed or parsed using the +`bazel analyze-profile` command. The Build profile can be useful in +understanding where Bazel's `build` command is spending its time. #### `--[no]show_loading_progress` {#show-loading-progress} @@ -1556,19 +1555,14 @@ failing status. Specifies how the test result summary should be displayed. -* `short` lists all tests that ran to completion, along with the name of - the file containing the test output if the test failed. This is the - default value. -* `short_uncached` like `short`, but omits tests whose results were cached. -* `terse` lists only failed and flaky tests. -* `detailed` lists all tests that ran to completion and prints each - individual test case (passed, skipped, and failed). The names of test - output files are omitted. -* `detailed_uncached` like `detailed`, but omits tests whose results were - cached. -* `testcase` prints a summary at test-case resolution without detailed - information about failed test cases. -* `none` does not print a test summary. +* `short` prints the results of each test along with the name of + the file containing the test output if the test failed. This is the default + value. +* `terse` like `short`, but even shorter: only print + information about tests which did not pass. +* `detailed` prints each individual test case that failed, not + only each test. The names of test output files are omitted. +* `none` does not print test summary. #### `--test_output=output_style` {#test-output} @@ -1603,10 +1597,10 @@ be formatted to stay within 80 characters when possible. #### `--test_tmpdir=path` {#test-tmpdir} -Specifies temporary directory for tests. Each test will be executed in a -separate subdirectory inside this directory. The directory will be cleaned at -the beginning of each `bazel test` command. -By default, Bazel will place this directory under the Bazel output base directory. +Specifies temporary directory for tests executed locally. Each test will be +executed in a separate subdirectory inside this directory. The directory will +be cleaned at the beginning of the each `bazel test` command. +By default, bazel will place this directory under Bazel output base directory. Note: This is a directory for running tests, not storing test results (those are always stored under the `bazel-out` directory). @@ -2212,6 +2206,12 @@ Example: % pprof -flame $HOME/prof.gz +### `analyze-profile` {#analyze-profile} + +The `analyze-profile` command analyzes a +[JSON trace profile](/advanced/performance/json-trace-profile) previously +gathered during a Bazel invocation. + ### `canonicalize-flags` {#canonicalize-flags} The [`canonicalize-flags`](/reference/command-line-reference#canonicalize-flags-options) @@ -2496,4 +2496,4 @@ enabled under the same conditions as for `--color=auto`. #### `--[no]show_timestamps` {#show-timestamps} If specified, a timestamp is added to each message generated by -Bazel specifying the time at which the message was output. +Bazel specifying the time at which the message was displayed. diff --git a/extending/config.mdx b/extending/config.mdx index 5010ed6bd..2e1331c08 100644 --- a/extending/config.mdx +++ b/extending/config.mdx @@ -665,34 +665,6 @@ hot_chocolate_transition = transition( ) ``` -### Composing transitions {#composing-transitions} - -Two transitions can be combined into a single new transition using -[`transition.and_then`](/rules/lib/builtins/transition#and_then): - -```python -combined_transition = first_transition.and_then(second_transition) -``` - -The composition applies `first_transition` to the input configuration and then -runs `second_transition` against each of its output configurations. The original -transitions are not modified, and the result is itself a `transition` object -that can be composed further with another `and_then` call. - -A composed transition can be attached to a rule or attribute wherever its -component transitions could be used (subject to the usual restriction that an -[incoming edge transition](#incoming-edge-transitions) must be 1:1). At most one -of the composed transitions may be an exec transition (`"exec"` or -[`config.exec`](/rules/lib/toplevel/config#exec)). - -When two of the composed transitions are 1:2+, the composition produces the -cross product of their splits. The key for each combined split is the -comma-separated concatenation of the component keys: if the first transition -produces keys `{a, b}` and the second produces `{x, y}` for each of those, the -composition produces the four keys `a,x`, `a,y`, `b,x`, and `b,y`. Note that -each additional 1:2+ transition multiplies the resulting dependency count, so -chain them with care. - ### Accessing attributes with transitions {#accessing-attributes-with-transitions} [End to end example](https://github.com/bazelbuild/examples/tree/HEAD/configurations/read_attr_in_transition) diff --git a/extending/rules.mdx b/extending/rules.mdx index 1b2e050b4..976d46ac6 100644 --- a/extending/rules.mdx +++ b/extending/rules.mdx @@ -820,7 +820,7 @@ Tools that are executed as part of the build (such as compilers or code generato should be built for an exec configuration. In this case, specify `cfg = "exec"` in the attribute. -Otherwise, executables that are used at runtime (e.g. as part of a test) should +Otherwise, executables that are used at runtime (such as as part of a test) should be built for the target configuration. In this case, specify `cfg = "target"` in the attribute. diff --git a/install/compile-source.mdx b/install/compile-source.mdx index 0c341b208..9479e0cb9 100644 --- a/install/compile-source.mdx +++ b/install/compile-source.mdx @@ -189,7 +189,7 @@ You can also build Bazel from scratch, without using an existing Bazel binary. 2. Unpack the distribution archive somewhere on disk. You should verify the signature made by Bazel's - [release key](https://releases.bazel.build/bazel-release.pub.gpg) 3D5919B448457EE0. + [release key](https://bazel.build/bazel-release.pub.gpg) 3D5919B448457EE0. ### Step 2a: Bootstrap Bazel on Ubuntu Linux, macOS, and other Unix-like systems {#bootstrap-unix-overview} diff --git a/install/ubuntu.mdx b/install/ubuntu.mdx index 7ea98ce5a..c1e4e32ec 100644 --- a/install/ubuntu.mdx +++ b/install/ubuntu.mdx @@ -43,7 +43,7 @@ Bazel comes with two completion scripts. After installing Bazel, you can: ```posix-terminal sudo apt install apt-transport-https curl gnupg -y -curl -fsSL https://releases.bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg +curl -fsSL https://bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg sudo mv bazel-archive-keyring.gpg /usr/share/keyrings diff --git a/migrate/xcode.mdx b/migrate/xcode.mdx index 9c3668779..5f6a05a21 100644 --- a/migrate/xcode.mdx +++ b/migrate/xcode.mdx @@ -115,7 +115,7 @@ In the target, specify the following at the minimum: binary. * `provisioning_profile` - provisioning profile from your Apple Developer - account (if building for an iOS device). + account (if building for an iOS device device). * `families` (iOS only) - whether to build the application for iPhone, iPad, or both. diff --git a/navigation.json b/navigation.json index 24f53ff48..99f6ff9e9 100644 --- a/navigation.json +++ b/navigation.json @@ -24,14 +24,6 @@ } ] }, - { - "version": "8.7", - "languages": [ - { - "$ref": "./navigation/8.7.en.json" - } - ] - }, { "version": "8.6", "languages": [ diff --git a/navigation/HEAD.en.json b/navigation/HEAD.en.json index e4fb8a313..6f75528a2 100644 --- a/navigation/HEAD.en.json +++ b/navigation/HEAD.en.json @@ -180,6 +180,13 @@ "pages": [ "reference/flag-cheatsheet" ] + }, + { + "group": "Skyframe", + "pages": [ + "reference/skyframe", + "reference/skyframe-debugging" + ] } ] }, diff --git a/query/cquery.mdx b/query/cquery.mdx index 86c2d5ff8..f7195d405 100644 --- a/query/cquery.mdx +++ b/query/cquery.mdx @@ -546,7 +546,7 @@ that is, it configures its tools in the [exec configuration](https://bazel.build You can see the lingering effects of that transition below. ``` -$ cat > foo/BUILD <<<EOF +$ cat > foo/BUILD <<JUnit test result schema. optional diff --git a/release/index.mdx b/release/index.mdx index df4b1adc9..fa867888d 100644 --- a/release/index.mdx +++ b/release/index.mdx @@ -14,7 +14,7 @@ information about Bazel's release model. | LTS release | Support stage | Latest version | End of support | | ----------- | ------------- | -------------- | -------------- | | Bazel 10 | Rolling| [Check rolling release page](/release/rolling) | N/A | -| Bazel 9 | Active| [9.2.0](https://github.com/bazelbuild/bazel/releases/tag/9.2.0) | Dec 2028 | +| Bazel 9 | Active| [9.1.1](https://github.com/bazelbuild/bazel/releases/tag/9.1.1) | Dec 2028 | | Bazel 8 | Maintenance| [8.7.0](https://github.com/bazelbuild/bazel/releases/tag/8.7.0) | Dec 2027 | | Bazel 7 | Maintenance| [7.7.1](https://github.com/bazelbuild/bazel/releases/tag/7.7.1) | Dec 2026 | | Bazel 6 | Deprecated | [6.6.0](https://github.com/bazelbuild/bazel/releases/tag/6.6.0) | Dec 2025 | diff --git a/remote/output-directories.mdx b/remote/output-directories.mdx index f55e438a4..367108254 100644 --- a/remote/output-directories.mdx +++ b/remote/output-directories.mdx @@ -34,7 +34,7 @@ The solution that's currently implemented: and on Windows it defaults to `%HOME%` if set, else `%USERPROFILE%` if set, else the result of calling `SHGetKnownFolderPath()` with the `FOLDERID_Profile` flag set. If the environment variable `$XDG_CACHE_HOME` - is set on Linux, macOS, or Windows, the value `${XDG_CACHE_HOME}/bazel` will + is set on either Linux or macOS, the value `${XDG_CACHE_HOME}/bazel` will override the default. If the environment variable `$TEST_TMPDIR` is set, as in a test of Bazel itself, then that value overrides any defaults. * Note that Bazel 8.x and earlier on macOS used `/private/var/tmp` as _outputRoot_, diff --git a/remote/persistent.mdx b/remote/persistent.mdx index 831866357..c0e7f1daf 100644 --- a/remote/persistent.mdx +++ b/remote/persistent.mdx @@ -129,13 +129,7 @@ Passing the [`--worker_sandboxing`](/reference/command-line-reference#flag--worker_sandboxing) flag makes each worker request use a separate sandbox directory for all its inputs. Setting up the [sandbox](/docs/sandboxing) takes some extra time, -especially on macOS, but gives a better correctness guarantee. In addition to -the plain boolean form, the flag may be scoped to a worker-key mnemonic as -`--worker_sandboxing==`, allowing sandboxing to be enabled or -disabled per mnemonic (for example -`--worker_sandboxing --worker_sandboxing=Javac=no`). Later values override -earlier ones for the mnemonics they affect, so a later plain -`--worker_sandboxing` re-enables sandboxing for all mnemonics. +especially on macOS, but gives a better correctness guarantee. The [`--worker_quit_after_build`](/reference/command-line-reference#flag--worker_quit_after_build) @@ -243,8 +237,7 @@ might be helpful. Using the `worker` strategy by default does not run the action in a [sandbox](/docs/sandboxing), similar to the `local` strategy. You can set the `--worker_sandboxing` flag to run all workers inside sandboxes, making sure each -execution of the tool only sees the input files it's supposed to have, or scope -it per mnemonic with `--worker_sandboxing==`. The tool +execution of the tool only sees the input files it's supposed to have. The tool may still leak information between requests internally, for instance through a cache. Using `dynamic` strategy [requires workers to be sandboxed](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/exec/SpawnStrategyRegistry.java). diff --git a/remote/sandbox.mdx b/remote/sandbox.mdx index 26e9b89b9..de66ba6cb 100644 --- a/remote/sandbox.mdx +++ b/remote/sandbox.mdx @@ -95,7 +95,7 @@ machine and is a reliable way to confirm whether your build will succeed when executed remotely. However, with this method, locally installed tools, binaries, and data may leak -into your build, especially if it uses [configure-style WORKSPACE rules](/remote/rules#manage-workspace-rules). +into into your build, especially if it uses [configure-style WORKSPACE rules](/remote/rules#manage-workspace-rules). Such leaks will cause problems with remote execution; to detect them, [troubleshoot in a Docker container](#troubleshooting-docker-container) in addition to troubleshooting natively. diff --git a/rules/language.mdx b/rules/language.mdx index 5e5d10699..a29111d84 100644 --- a/rules/language.mdx +++ b/rules/language.mdx @@ -55,7 +55,7 @@ Starlark in Bazel at HEAD is incrementally adding support for type annotations with a syntax inspired by [PEP 484](https://peps.python.org/pep-0484/). - Starlark type annotations are under active development. The progress is - tracked on [issue#27370](https://github.com/bazelbuild/bazel/issues/27370). + tracked on [issue#22935](https://github.com/bazelbuild/bazel/issues/22935). - The specification is incrementally extended: [starlark-with-types/spec.md](https://github.com/bazelbuild/starlark/blob/starlark-with-types/spec.md) - Initial proposal: [SEP-001 Bootstrapping Starlark types](https://docs.google.com/document/d/1Sid7EAbBd_w_T7D94Li_f_bK3zMTztFbzIMvcpzo1wY/edit?tab=t.0#heading=h.5mcn15i0e1ch) @@ -155,6 +155,7 @@ The following Python features are not supported: * `class` (see [`struct`](/rules/lib/builtins/struct#struct) function). * `import` (see [`load`](/extending/concepts#loading-an-extension) statement). * `while`, `yield`. +* float and set types. * generators and generator expressions. * `is` (use `==` instead). * `try`, `raise`, `except`, `finally` (see [`fail`](/rules/lib/globals#fail) for fatal errors). diff --git a/rules/rules-tutorial.mdx b/rules/rules-tutorial.mdx index 8246f6b7a..8510a81c5 100644 --- a/rules/rules-tutorial.mdx +++ b/rules/rules-tutorial.mdx @@ -147,7 +147,7 @@ bin2 ``` Whenever you declare a file, you have to tell Bazel how to generate it by -creating an [action](/extending/rules#actions). Use [`ctx.actions.write`](/rules/lib/builtins/actions#write), +creating an action. Use [`ctx.actions.write`](/rules/lib/builtins/actions#write), to create a file with the given content. ```python diff --git a/rules/testing.mdx b/rules/testing.mdx index 499fa929c..4642c9eaa 100644 --- a/rules/testing.mdx +++ b/rules/testing.mdx @@ -159,7 +159,7 @@ would be named `testFoo`. Then: -* the macro which generates the test and target under test should be +* the macro which generates the test and target under test should should be named `_test_foo` (`_test_provider_contents`) * its test rule type should be named `foo_test` (`provider_contents_test`) diff --git a/run/build.mdx b/run/build.mdx index cd36edf67..2f3e4825d 100644 --- a/run/build.mdx +++ b/run/build.mdx @@ -19,6 +19,7 @@ Usage: bazel command options ... ### Available commands {#available-commands} +* [`analyze-profile`](/docs/user-manual#analyze-profile): Analyzes build profile data. * [`aquery`](/docs/user-manual#aquery): Executes a query on the [post-analysis](#analysis) action graph. * [`build`](#bazel-build): Builds the specified targets. * [`canonicalize-flags`](/docs/user-manual#canonicalize-flags): Canonicalize Bazel flags. diff --git a/run/scripts.mdx b/run/scripts.mdx index 3a34e3852..fcf0ef858 100644 --- a/run/scripts.mdx +++ b/run/scripts.mdx @@ -55,7 +55,7 @@ Bazel execution can result in following exit codes: - `32` - External Environment Failure not on this machine. - `33` - Bazel ran out of memory and crashed. You need to modify your command line. -- `34` - Remote execution, remote cache, or Build Event Service error. +- `34` - Reserved for Google-internal use. - `35` - Reserved for Google-internal use. - `36` - Local Environmental Issue, suspected permanent. - `37` - Unhandled Exception / Internal Bazel Error. @@ -64,7 +64,6 @@ Bazel execution can result in following exit codes: - `41-44` - Reserved for Google-internal use. - `45` - Persistent error publishing results to the Build Event Service. - `47` - Reserved for Google-internal use. -- `48` - External dependency error. - `49` - Reserved for Google-internal use. **Return codes for commands `bazel build`, `bazel test`:** diff --git a/upstream b/upstream index f644f2dff..c031e7b43 160000 --- a/upstream +++ b/upstream @@ -1 +1 @@ -Subproject commit f644f2dff90cbbba0e14551051578c5e93328650 +Subproject commit c031e7b4322345f098fe8fc380eae61664d56d52 diff --git a/versions/7.6.1/install/ubuntu.mdx b/versions/7.6.1/install/ubuntu.mdx index 303559411..51556f919 100644 --- a/versions/7.6.1/install/ubuntu.mdx +++ b/versions/7.6.1/install/ubuntu.mdx @@ -40,7 +40,7 @@ Bazel comes with two completion scripts. After installing Bazel, you can: ```posix-terminal sudo apt install apt-transport-https curl gnupg -y -curl -fsSL https://releases.bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg +curl -fsSL https://bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg sudo mv bazel-archive-keyring.gpg /usr/share/keyrings echo "deb [arch=amd64 signed-by=/usr/share/keyrings/bazel-archive-keyring.gpg] https://storage.googleapis.com/bazel-apt stable jdk1.8" | sudo tee /etc/apt/sources.list.d/bazel.list ``` diff --git a/versions/7.6.1/reference/test-encyclopedia.mdx b/versions/7.6.1/reference/test-encyclopedia.mdx index 9109dcd23..2c6847cd5 100644 --- a/versions/7.6.1/reference/test-encyclopedia.mdx +++ b/versions/7.6.1/reference/test-encyclopedia.mdx @@ -446,7 +446,7 @@ The initial environment block shall be composed as follows: Location to which test actions should write a test result XML output file. Otherwise, Bazel generates a default XML output file wrapping the test log as part of the test action. The XML schema is based on the - + JUnit test result schema diff --git a/versions/7.7.1/install/ubuntu.mdx b/versions/7.7.1/install/ubuntu.mdx index 5fac25b43..d4bb33fd5 100644 --- a/versions/7.7.1/install/ubuntu.mdx +++ b/versions/7.7.1/install/ubuntu.mdx @@ -40,7 +40,7 @@ Bazel comes with two completion scripts. After installing Bazel, you can: ```posix-terminal sudo apt install apt-transport-https curl gnupg -y -curl -fsSL https://releases.bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg +curl -fsSL https://bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg sudo mv bazel-archive-keyring.gpg /usr/share/keyrings echo "deb [arch=amd64 signed-by=/usr/share/keyrings/bazel-archive-keyring.gpg] https://storage.googleapis.com/bazel-apt stable jdk1.8" | sudo tee /etc/apt/sources.list.d/bazel.list ``` diff --git a/versions/7.7.1/reference/test-encyclopedia.mdx b/versions/7.7.1/reference/test-encyclopedia.mdx index 2d0a13ee3..240448387 100644 --- a/versions/7.7.1/reference/test-encyclopedia.mdx +++ b/versions/7.7.1/reference/test-encyclopedia.mdx @@ -442,7 +442,7 @@ The initial environment block shall be composed as follows: XML_OUTPUT_FILE - Location to which test actions should write a test result XML output file. Otherwise, Bazel generates a default XML output file wrapping the test log as part of the test action. The XML schema is based on the JUnit test result schema. + Location to which test actions should write a test result XML output file. Otherwise, Bazel generates a default XML output file wrapping the test log as part of the test action. The XML schema is based on the JUnit test result schema. optional diff --git a/versions/8.0.1/install/ubuntu.mdx b/versions/8.0.1/install/ubuntu.mdx index de5ea2166..0884da354 100644 --- a/versions/8.0.1/install/ubuntu.mdx +++ b/versions/8.0.1/install/ubuntu.mdx @@ -41,7 +41,7 @@ Bazel comes with two completion scripts. After installing Bazel, you can: ```posix-terminal sudo apt install apt-transport-https curl gnupg -y -curl -fsSL https://releases.bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg +curl -fsSL https://bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg sudo mv bazel-archive-keyring.gpg /usr/share/keyrings diff --git a/versions/8.0.1/reference/test-encyclopedia.mdx b/versions/8.0.1/reference/test-encyclopedia.mdx index cf7844b40..70cb7f4b1 100644 --- a/versions/8.0.1/reference/test-encyclopedia.mdx +++ b/versions/8.0.1/reference/test-encyclopedia.mdx @@ -446,7 +446,7 @@ The initial environment block shall be composed as follows: Location to which test actions should write a test result XML output file. Otherwise, Bazel generates a default XML output file wrapping the test log as part of the test action. The XML schema is based on the - JUnit test result schema. optional diff --git a/versions/8.1.1/install/ubuntu.mdx b/versions/8.1.1/install/ubuntu.mdx index c9ad913a5..20d692ef2 100644 --- a/versions/8.1.1/install/ubuntu.mdx +++ b/versions/8.1.1/install/ubuntu.mdx @@ -41,7 +41,7 @@ Bazel comes with two completion scripts. After installing Bazel, you can: ```posix-terminal sudo apt install apt-transport-https curl gnupg -y -curl -fsSL https://releases.bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg +curl -fsSL https://bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg sudo mv bazel-archive-keyring.gpg /usr/share/keyrings diff --git a/versions/8.1.1/reference/test-encyclopedia.mdx b/versions/8.1.1/reference/test-encyclopedia.mdx index dfae507f0..84dffce10 100644 --- a/versions/8.1.1/reference/test-encyclopedia.mdx +++ b/versions/8.1.1/reference/test-encyclopedia.mdx @@ -446,7 +446,7 @@ The initial environment block shall be composed as follows: Location to which test actions should write a test result XML output file. Otherwise, Bazel generates a default XML output file wrapping the test log as part of the test action. The XML schema is based on the - JUnit test result schema. optional diff --git a/versions/8.2.1/install/ubuntu.mdx b/versions/8.2.1/install/ubuntu.mdx index 4b808714b..c9ecfa056 100644 --- a/versions/8.2.1/install/ubuntu.mdx +++ b/versions/8.2.1/install/ubuntu.mdx @@ -41,7 +41,7 @@ Bazel comes with two completion scripts. After installing Bazel, you can: ```posix-terminal sudo apt install apt-transport-https curl gnupg -y -curl -fsSL https://releases.bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg +curl -fsSL https://bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg sudo mv bazel-archive-keyring.gpg /usr/share/keyrings diff --git a/versions/8.2.1/reference/test-encyclopedia.mdx b/versions/8.2.1/reference/test-encyclopedia.mdx index 1e79e320d..d137a7f2f 100644 --- a/versions/8.2.1/reference/test-encyclopedia.mdx +++ b/versions/8.2.1/reference/test-encyclopedia.mdx @@ -446,7 +446,7 @@ The initial environment block shall be composed as follows: Location to which test actions should write a test result XML output file. Otherwise, Bazel generates a default XML output file wrapping the test log as part of the test action. The XML schema is based on the - JUnit test result schema. optional diff --git a/versions/8.3.1/install/ubuntu.mdx b/versions/8.3.1/install/ubuntu.mdx index 63d2835a6..8c9de2efa 100644 --- a/versions/8.3.1/install/ubuntu.mdx +++ b/versions/8.3.1/install/ubuntu.mdx @@ -41,7 +41,7 @@ Bazel comes with two completion scripts. After installing Bazel, you can: ```posix-terminal sudo apt install apt-transport-https curl gnupg -y -curl -fsSL https://releases.bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg +curl -fsSL https://bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg sudo mv bazel-archive-keyring.gpg /usr/share/keyrings diff --git a/versions/8.3.1/reference/test-encyclopedia.mdx b/versions/8.3.1/reference/test-encyclopedia.mdx index f284b907f..816d179e0 100644 --- a/versions/8.3.1/reference/test-encyclopedia.mdx +++ b/versions/8.3.1/reference/test-encyclopedia.mdx @@ -446,7 +446,7 @@ The initial environment block shall be composed as follows: Location to which test actions should write a test result XML output file. Otherwise, Bazel generates a default XML output file wrapping the test log as part of the test action. The XML schema is based on the - JUnit test result schema. + JUnit test result schema. optional diff --git a/versions/8.4.2/install/ubuntu.mdx b/versions/8.4.2/install/ubuntu.mdx index d7b4b8b54..b52c61df8 100644 --- a/versions/8.4.2/install/ubuntu.mdx +++ b/versions/8.4.2/install/ubuntu.mdx @@ -41,7 +41,7 @@ Bazel comes with two completion scripts. After installing Bazel, you can: ```posix-terminal sudo apt install apt-transport-https curl gnupg -y -curl -fsSL https://releases.bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg +curl -fsSL https://bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg sudo mv bazel-archive-keyring.gpg /usr/share/keyrings diff --git a/versions/8.4.2/reference/test-encyclopedia.mdx b/versions/8.4.2/reference/test-encyclopedia.mdx index fbcfec2c5..b2b7458b2 100644 --- a/versions/8.4.2/reference/test-encyclopedia.mdx +++ b/versions/8.4.2/reference/test-encyclopedia.mdx @@ -446,7 +446,7 @@ The initial environment block shall be composed as follows: Location to which test actions should write a test result XML output file. Otherwise, Bazel generates a default XML output file wrapping the test log as part of the test action. The XML schema is based on the - JUnit test result schema. optional diff --git a/versions/8.5.1/install/ubuntu.mdx b/versions/8.5.1/install/ubuntu.mdx index e20b5c482..023b9539b 100644 --- a/versions/8.5.1/install/ubuntu.mdx +++ b/versions/8.5.1/install/ubuntu.mdx @@ -41,7 +41,7 @@ Bazel comes with two completion scripts. After installing Bazel, you can: ```posix-terminal sudo apt install apt-transport-https curl gnupg -y -curl -fsSL https://releases.bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg +curl -fsSL https://bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg sudo mv bazel-archive-keyring.gpg /usr/share/keyrings diff --git a/versions/8.5.1/reference/test-encyclopedia.mdx b/versions/8.5.1/reference/test-encyclopedia.mdx index c07e60c30..e6f45dafb 100644 --- a/versions/8.5.1/reference/test-encyclopedia.mdx +++ b/versions/8.5.1/reference/test-encyclopedia.mdx @@ -446,7 +446,7 @@ The initial environment block shall be composed as follows: Location to which test actions should write a test result XML output file. Otherwise, Bazel generates a default XML output file wrapping the test log as part of the test action. The XML schema is based on the - JUnit test result schema. optional diff --git a/versions/8.6.0/reference/test-encyclopedia.mdx b/versions/8.6.0/reference/test-encyclopedia.mdx index e8522a8f4..8d8539a24 100644 --- a/versions/8.6.0/reference/test-encyclopedia.mdx +++ b/versions/8.6.0/reference/test-encyclopedia.mdx @@ -454,7 +454,7 @@ The initial environment block shall be composed as follows: Location to which test actions should write a test result XML output file. Otherwise, Bazel generates a default XML output file wrapping the test log as part of the test action. The XML schema is based on the - JUnit test result schema. optional diff --git a/versions/9.0.0/install/ubuntu.mdx b/versions/9.0.0/install/ubuntu.mdx index 79fd59b38..0b3ef32c6 100644 --- a/versions/9.0.0/install/ubuntu.mdx +++ b/versions/9.0.0/install/ubuntu.mdx @@ -41,7 +41,7 @@ Bazel comes with two completion scripts. After installing Bazel, you can: ```posix-terminal sudo apt install apt-transport-https curl gnupg -y -curl -fsSL https://releases.bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg +curl -fsSL https://bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg sudo mv bazel-archive-keyring.gpg /usr/share/keyrings diff --git a/versions/9.0.0/reference/test-encyclopedia.mdx b/versions/9.0.0/reference/test-encyclopedia.mdx index 0a0cb45b3..dc8badddb 100644 --- a/versions/9.0.0/reference/test-encyclopedia.mdx +++ b/versions/9.0.0/reference/test-encyclopedia.mdx @@ -446,7 +446,7 @@ The initial environment block shall be composed as follows: Location to which test actions should write a test result XML output file. Otherwise, Bazel generates a default XML output file wrapping the test log as part of the test action. The XML schema is based on the - JUnit test result schema. optional diff --git a/versions/9.1.0/install/ubuntu.mdx b/versions/9.1.0/install/ubuntu.mdx index 2004c9a63..fdbc26ef4 100644 --- a/versions/9.1.0/install/ubuntu.mdx +++ b/versions/9.1.0/install/ubuntu.mdx @@ -41,7 +41,7 @@ Bazel comes with two completion scripts. After installing Bazel, you can: ```posix-terminal sudo apt install apt-transport-https curl gnupg -y -curl -fsSL https://releases.bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg +curl -fsSL https://bazel.build/bazel-release.pub.gpg | gpg --dearmor >bazel-archive-keyring.gpg sudo mv bazel-archive-keyring.gpg /usr/share/keyrings diff --git a/versions/9.1.0/reference/test-encyclopedia.mdx b/versions/9.1.0/reference/test-encyclopedia.mdx index 2532e1a89..c3ebe311f 100644 --- a/versions/9.1.0/reference/test-encyclopedia.mdx +++ b/versions/9.1.0/reference/test-encyclopedia.mdx @@ -453,7 +453,7 @@ The initial environment block shall be composed as follows: Location to which test actions should write a test result XML output file. Otherwise, Bazel generates a default XML output file wrapping the test log as part of the test action. The XML schema is based on the - JUnit test result schema. optional