build(deps): bump upstream from ad2e223 to 37654e5

contribute/breaking-changes.mdx

@@ -69,7 +69,7 @@ should contain the URL of the GitHub issue. As the flag name starts with
 ```
 
 In the commit description, add a brief summary of the flag.
-Also add [`RELNOTES:`](release-notes.md) in the following form:
+Also add [`RELNOTES:`](/contribute/release-notes) in the following form:
 `RELNOTES: --incompatible_name_of_flag has been added. See #xyz for details`
 
 The commit should also update the relevant documentation, so that there is no

contribute/design-documents.mdx

@@ -27,7 +27,7 @@ Here are some examples of significant changes:
 When you write a design document, you can coordinate with other Bazel developers
 and seek guidance from Bazel's core team. For example, when a proposal adds,
 removes, or modifies any function or object available in BUILD, MODULE.bazel, or
-bzl files, add the [Starlark team](maintainers-guide.md) as reviewers.
+bzl files, add the [Starlark team](/contribute/maintainers-guide) as reviewers.
 Design documents are reviewed before submission because:
 
 *   Bazel is a very complex system; seemingly innocuous local changes can have

docs/bazel-and-android.mdx

@@ -12,7 +12,7 @@ Android projects with Bazel.
 
 The following resources will help you work with Bazel on Android projects:
 
-*  [Tutorial: Building an Android app](/start/android-app ). This
+*  [Tutorial: Building an Android app](/start/android-app). This
    tutorial is a good place to start learning about Bazel commands and concepts,
    and how to build Android apps with Bazel.
 *  [Codelab: Building Android Apps with Bazel](https://developer.android.com/codelabs/bazel-android-intro#0).

docs/sandboxing.mdx

@@ -50,7 +50,7 @@ containers on Linux and `sandbox-exec` on macOS, to constrain the action within
 ## What sandbox strategy to use {#sandboxing-strategies}
 
 You can choose which kind of sandboxing to use, if any, with the
-[strategy flags](user-manual.html#strategy-options). Using the `sandboxed`
+[strategy flags](/docs/user-manual#strategy-options). Using the `sandboxed`
 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

extending/legacy-macros.mdx

@@ -11,7 +11,7 @@ anymore, and Bazel sees only the concrete set of instantiated rules.
 
 ## Why you shouldn't use legacy macros (and should use Symbolic macros instead) {#no-legacy-macros}
 
-Where possible you should use [symbolic macros](macros.md#macros).
+Where possible you should use [symbolic macros](/extending/macros#macros).
 
 Symbolic macros
 
@@ -20,7 +20,7 @@ Symbolic macros
 *   Take typed attributes, which in turn means automatic label and select
     conversion.
 *   Are more readable
-*   Will soon have [lazy evaluation](macros.md#laziness)
+*   Will soon have [lazy evaluation](/extending/macros#laziness)
 
 ## Usage {#usage}
 
@@ -154,7 +154,7 @@ the macro), use the function
 ## Label resolution in macros {#label-resolution}
 
 Since legacy macros are evaluated in the
-[loading phase](concepts.md#evaluation-model), label strings such as
+[loading phase](/extending/concepts#evaluation-model), label strings such as
 `"//foo:bar"` that occur in a legacy macro are interpreted relative to the
 `BUILD` file in which the macro is used rather than relative to the `.bzl` file
 in which it is defined. This behavior is generally undesirable for macros that

extending/macros.mdx

@@ -12,7 +12,7 @@ Macros are mainly used for encapsulation and code reuse of existing rules and
 other macros.
 
 Macros come in two flavors: symbolic macros, which are described on this page,
-and [legacy macros](legacy-macros.md). Where possible, we recommend using
+and [legacy macros](/extending/legacy-macros). Where possible, we recommend using
 symbolic macros for code clarity.
 
 Symbolic macros offer typed arguments (string to label conversion, relative to

extending/rules.mdx

@@ -542,7 +542,7 @@ provider instances satisfy certain invariants, or to give users a cleaner API fo
 obtaining an instance.
 
 This is done by passing an `init` callback to the
-[`provider`](/rules/lib/globals/bzl.html#provider) function. If this callback is given, the
+[`provider`](/rules/lib/globals/bzl#provider) function. If this callback is given, the
 return type of `provider()` changes to be a tuple of two values: the provider
 symbol that is the ordinary return value when `init` is not used, and a "raw
 constructor".

external/faq.mdx

@@ -76,7 +76,7 @@ failures provide clear error messages and actionable migration paths.
 
 **Legacy documentation:**
 
-The [`compatibility_level`](module.md#compatibility_level) of a Bazel module
+The [`compatibility_level`](/external/module#compatibility_level) of a Bazel module
 should be incremented _in the same commit_ that introduces a backwards
 incompatible ("breaking") change.
 
@@ -114,7 +114,7 @@ generally interested in, and they can be solved without `load`s:
     `load`s in MODULE.bazel files, `include` cannot be used in non-root modules.
 *   Users of the old WORKSPACE system might remember declaring a repo, and then
     immediately `load`ing from that repo to perform complex logic. This
-    capability has been replaced by [module extensions](extension).
+    capability has been replaced by [module extensions](/external/extension).
 
 ### Can I specify a SemVer range for a `bazel_dep`? {#can-i-specify-a-semver-range-for-a-bazel-dep}
 
@@ -123,11 +123,11 @@ support version ranges (implicitly or explicitly), and this often requires a
 constraint solver (making the output harder to predict for users) and makes
 version resolution nonreproducible without a lockfile.
 
-Bazel instead uses [Minimal Version Selection](module#version-selection) like
+Bazel instead uses [Minimal Version Selection](/external/module#version-selection) like
 Go, which in contrast makes the output easy to predict and guarantees
 reproducibility. This is a tradeoff that matches Bazel's design goals.
 
-Furthermore, Bazel module versions are [a superset of SemVer](module#version-format), so what makes sense in a strict SemVer
+Furthermore, Bazel module versions are [a superset of SemVer](/external/module#version-format), so what makes sense in a strict SemVer
 environment doesn't always carry over to Bazel module versions.
 
 ### Can I automatically get the latest version for a `bazel_dep`? {#can-i-automatically-get-the-latest-version-for-a-bazel-dep}
@@ -192,7 +192,7 @@ wonder which system is consulted first. The short answer is that MODULE.bazel
 
 The long answer is that "which evaluates first" is not the right question to
 ask; rather, the right question to ask is: in the context of the repo with
-[canonical name](overview#canonical-repo-name) `@@foo`, what does the [apparent repo name](overview#apparent-repo-name) `@bar` resolve to? Alternatively, what
+[canonical name](/external/overview#canonical-repo-name) `@@foo`, what does the [apparent repo name](/external/overview#apparent-repo-name) `@bar` resolve to? Alternatively, what
 is the repo mapping of `@@base`?
 
 Labels with apparent repo names (a single leading `@`) can refer to different
@@ -201,7 +201,7 @@ things based on the context they're resolved from. When you see a label
 what the context repo is: for example, if the label is in a BUILD file located
 in the repo `@@foo`, then the context repo is `@@foo`.
 
-Then, depending on what the context repo is, the ["repository visibility" table](migration#repository-visibility) in the migration guide can
+Then, depending on what the context repo is, the ["repository visibility" table](/external/migration#repository-visibility) in the migration guide can
 be used to find out which repo an apparent name actually resolves to.
 
 *   If the context repo is the main repo (`@@`):
@@ -261,7 +261,7 @@ To make sure no fetches happen during a build, use `--nofetch`. More precisely,
 this makes any attempt to run a non-local repository rule fail.
 
 If you want to fetch repos _and_ modify them to test locally, consider using
-the [`bazel vendor`](vendor) command.
+the [`bazel vendor`](/external/vendor) command.
 
 ### How do I insulate my builds from the Internet? {#how-do-i-insulate-my-builds-from-the-internet}
 

external/migration.mdx

@@ -11,7 +11,7 @@ your project to Bzlmod and drop WORKSPACE for managing external dependencies.
 
 ## Why migrate to Bzlmod? {#why-migrate-to-bzlmod}
 
-*   There are many [advantages](overview#benefits) compared to the legacy
+*   There are many [advantages](/external/overview#benefits) compared to the legacy
     WORKSPACE system, which helps to ensure a healthy growth of the Bazel
     ecosystem.
 

external/mod-command.mdx

@@ -64,9 +64,9 @@ The available subcommands and their respective required arguments are:
 
 *   `<name>`: All present versions of the module `<name>`.
 
-*   `@<repo_name>`: The repo with the given [apparent name](overview#apparent-repo-name) in the context of the `--base_module`.
+*   `@<repo_name>`: The repo with the given [apparent name](/external/overview#apparent-repo-name) in the context of the `--base_module`.
 
-*   `@@<repo_name>`: The repo with the given [canonical name](overview#canonical-repo-name).
+*   `@@<repo_name>`: The repo with the given [canonical name](/external/overview#canonical-repo-name).
 
 In a context requiring specifying modules, `<arg>`s referring to repos that
 correspond to modules (as opposed to extension-generated repos) can also be
@@ -90,7 +90,7 @@ The following options only affect the subcommands that print graphs (`graph`,
     information about the version resolution of each module. If the module
     version changed during resolution, show either which version replaced it or
     what was the original version, the reason it was replaced, and which modules
-    requested the new version if the reason was [Minimal Version Selection](module#version-selection).
+    requested the new version if the reason was [Minimal Version Selection](/external/module#version-selection).
 
 *   `--include_unused` *default: "false"*: Include in the output graph the
     modules which were originally present in the dependency graph, but became

external/module.mdx

@@ -56,7 +56,7 @@ Any valid SemVer version is a valid Bazel module version. Additionally, two
 SemVer versions `a` and `b` compare `a < b` if and only if the same holds when
 they're compared as Bazel module versions.
 
-Finally, to learn more about module versioning, [see the `MODULE.bazel` FAQ](faq#module-versioning-best-practices).
+Finally, to learn more about module versioning, [see the `MODULE.bazel` FAQ](/external/faq#module-versioning-best-practices).
 
 ## Version selection {#version-selection}
 
@@ -151,7 +151,7 @@ Bazel supports the following non-registry overrides:
 
 Note that setting a version value in the source archive `MODULE.bazel` can have
 downsides when the module is being overridden with a non-registry override. To
-learn more about this [see the `MODULE.bazel` FAQ](faq#module-versioning-best-practices).
+learn more about this [see the `MODULE.bazel` FAQ](/external/faq#module-versioning-best-practices).
 
 ## Define repos that don't represent Bazel modules {#use_repo_rule}
 

external/overview.mdx

@@ -32,7 +32,7 @@ bazel_dep(name = "platforms", version = "0.0.11")
 ```
 
 From there, Bazel looks up all transitive dependency modules in a
-[*Bazel registry*](registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
+[*Bazel registry*](/external/registry) — by default, the [Bazel Central Registry](https://bcr.bazel.build/). The registry provides the
 dependencies' `MODULE.bazel` files, which allows Bazel to discover the entire
 transitive dependency graph before performing version resolution.
 
@@ -42,7 +42,7 @@ Bazel consults the registry again to learn how to define a repo for each module
 of the time, these are just archives downloaded from the internet and extracted.
 
 Modules can also specify customized pieces of data called *tags*, which are
-consumed by [*module extensions*](extension) after module resolution
+consumed by [*module extensions*](/external/extension) after module resolution
 to define additional repos. These extensions can perform actions like file I/O
 and sending network requests. Among other things, they allow Bazel to interact
 with other package management systems while also respecting the dependency graph
@@ -61,12 +61,12 @@ Bazel's external dependency system offers a wide range of benefits.
 ### Automatic Dependency Resolution {#automatic-dependency-resolution}
 
 -   **Deterministic Version Resolution**: Bazel adopts the deterministic
-    [MVS](module#version-selection) version resolution algorithm,
+    [MVS](/external/module#version-selection) version resolution algorithm,
     minimizing conflicts and addressing diamond dependency issues.
 -   **Simplified Dependency Management**: `MODULE.bazel` declares only direct
     dependencies, while transitive dependencies are automatically resolved,
     providing a clearer overview of the project's dependencies.
--   **[Strict Dependency visibility](module#repository_names_and_strict_deps)**:
+-   **[Strict Dependency visibility](/external/module#repository_names_and_strict_deps)**:
     Only direct dependencies are visible, ensuring correctness and
     predictability.
 
@@ -93,16 +93,16 @@ Bazel's external dependency system offers a wide range of benefits.
 
 ### Advanced Features {#advanced-features}
 
--   **[Module Extensions](extension)**: The
+-   **[Module Extensions](/external/extension)**: The
     [`use_repo_rule`](/rules/lib/globals/module#use_repo_rule) and module
     extension features allow flexible use of custom repository rules and
     resolution logic to introduce any non-Bazel dependencies.
--   **[`bazel mod` Command](mod-command)**: The sub-command offers
+-   **[`bazel mod` Command](/external/mod-command)**: The sub-command offers
     powerful ways to inspect external dependencies. You know exactly how an
     external dependency is defined and where it comes from.
--   **[Vendor Mode](vendor)**: Pre-fetch the exact external dependencies you
+-   **[Vendor Mode](/external/vendor)**: Pre-fetch the exact external dependencies you
     need to facilitate offline builds.
--   **[Lockfile](lockfile)**: The lockfile improves build reproducibility and
+-   **[Lockfile](/external/lockfile)**: The lockfile improves build reproducibility and
     accelerates dependency resolution.
 -   **(Upcoming) [BCR Provenance Attestations](https://github.com/bazelbuild/bazel-central-registry/discussions/2721)**:
     Strengthen supply chain security by ensuring verified provenance of
@@ -119,7 +119,7 @@ dependencies on other modules.
 
 In a local Bazel workspace, a module is represented by a repository.
 
-For more details, see [Bazel modules](module).
+For more details, see [Bazel modules](/external/module).
 
 ### Repository {#repository}
 
@@ -177,7 +177,7 @@ and extract it", or "fetch a certain Maven artifact and make it available as a
 `java_import` target", or simply "symlink a local directory". Every repo is
 **defined** by calling a repo rule with an appropriate number of arguments.
 
-See [Repository rules](repo) for more information about how to write
+See [Repository rules](/external/repo) for more information about how to write
 your own repository rules.
 
 The most common repo rules by far are
@@ -289,7 +289,7 @@ pain points, including:
 
 Due to the shortcomings of WORKSPACE, the new module-based system (codenamed
 "Bzlmod") gradually replaced the legacy WORKSPACE system between Bazel 6 and 9.
-Read the [Bzlmod migration guide](migration) on how to migrate
+Read the [Bzlmod migration guide](/external/migration) on how to migrate
 to Bzlmod.
 
 ### External links on Bzlmod {#external-links}

external/registry.mdx

@@ -29,7 +29,7 @@ An index registry must have the following format:
         there's a [non-registry override](/external/module#non-registry_overrides)). Also note that it's
         best to use this file to set the version of a release and avoid doing so
         in the source archive `MODULE.bazel` file. To learn more about module
-        versioning, [see the FAQ](faq.md#module-versioning-best-practices).
+        versioning, [see the FAQ](/external/faq#module-versioning-best-practices).
     *   [`source.json`](#source-json): A JSON file containing information on how
         to fetch the source of this module version
     *   `patches/`: An optional directory containing patch files, only used when

install/index.mdx

@@ -22,7 +22,7 @@ officially support them. Contact the package maintainers for support.
 *   [Fedora](https://copr.fedorainfracloud.org/coprs/lihaohong/bazel)
 *   [FreeBSD](https://www.freshports.org/devel/bazel)
 *   [Homebrew](https://formulae.brew.sh/formula/bazel)
-*   [mise](install/mise)
+*   [mise](/install/mise)
 *   [Nixpkgs](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/build-managers/bazel)
 *   [openSUSE](/install/suse)
 *   [Scoop](https://github.com/scoopinstaller/scoop-main/blob/master/bucket/bazel.json)