docs preview: bazelbuild/bazel#29499

contribute/docs-contribution-workflow.mdx

@@ -0,0 +1,220 @@
+---
+title: 'Docs contribution workflow'
+---
+
+This page guides you through contributing to the Bazel
+documentation, from a one-line typo fix to adding a new page. For style
+guidance, see the [Bazel docs style guide](/contribute/docs-style-guide).
+
+## Bazel docs structure {#structure}
+
+Bazel documentation lives in two repositories:
+
+| Repository | What it contains |
+|---|---|
+| [`bazelbuild/bazel`](https://github.com/bazelbuild/bazel) | All doc content (`docs/` folder). **This is where you make changes.** |
+| [`bazel-contrib/bazel-docs`](https://github.com/bazel-contrib/bazel-docs) | The hosting pipeline. Syncs from `bazelbuild/bazel` and deploys to [preview.bazel.build](https://preview.bazel.build). |
+
+Doc files are in [MDX format](https://mdxjs.com/), which is Markdown with a YAML
+frontmatter block at the top. Every page must start with:
+
+```
+---
+title: 'Your Page Title'
+---
+```
+
+## Prerequisites {#prerequisites}
+
+Before you start, you need:
+
+- A [GitHub account](https://github.com) 
+- A fork of [`bazelbuild/bazel`](https://github.com/bazelbuild/bazel)
+- [Git](https://git-scm.com/)
+- The [Mintlify CLI](https://www.mintlify.com/docs/cli/install) for local preview.  
+
+## Type 1: Quick fix {#quick-fix}
+
+For small isolated changes, such as a typo, broken link, phrasing tweaks, you can edit directly in the GitHub web UI without
+cloning anything.
+
+1. Find the file in
+   [`bazelbuild/bazel/docs/`](https://github.com/bazelbuild/bazel/tree/master/docs)
+   on GitHub.
+2. To edit the file, click the **pencil icon** in the top-right corner.
+3. Make your edit.
+4. Click **Commit changes...**, provide a commit message, and click **Propose changes"**.
+5. GitHub prompts you to open a pull request. Set the base branch to
+   **`master`** and click **Create pull request** it.
+
+## Type 2: Updating existing content {#updating-content}
+
+Use this workflow for anything larger than a typo, such as rewording a section,
+correcting outdated information, or adding a paragraph to an existing page.
+
+### Set up locally
+
+Fork [`bazelbuild/bazel`](https://github.com/bazelbuild/bazel) on GitHub first, then clone the repo and add the upstream remote:
+
+```bash
+git clone https://github.com/YOUR_USERNAME/bazel.git
+cd bazel
+git remote add upstream https://github.com/bazelbuild/bazel.git
+```
+
+### Make and preview your changes
+
+Check out a new branch off of `master`.
+
+```bash
+git fetch upstream
+git checkout -b my-doc-fix upstream/master
+```
+
+Edit the file in `docs/`, for example, `docs/concepts/labels.mdx`.
+
+To preview locally, you need a local copy of `bazel-contrib/bazel-docs`:
+
+```bash
+# One-time setup
+git clone https://github.com/bazel-contrib/bazel-docs.git
+cd bazel-docs
+```
+
+Copy your changed file(s) into the local `bazel-docs` mirror to preview them:
+
+```bash
+cp ~/path/to/bazel/docs/concepts/labels.mdx concepts/labels.mdx
+
+# Start the local dev server
+mintlify dev
+```
+
+Open [http://localhost:3000](http://localhost:3000) to render your changes.
+
+### Commit and open a PR
+
+Add, commit, and push your changes:
+```bash
+git add --all # stage all changes 
+git commit -m "docs: your commit msg here"
+git push origin my-doc-fix # push to GitHub
+```
+
+Open a pull request on GitHub from your fork to **`bazelbuild/bazel` master**.
+
+## Type 3: Adding a new section to an existing page {#new-section}
+
+Follow the same workflow as Type 2. A few things to keep in mind:
+
+**Add a heading anchor ID.** Every heading should have an explicit `{#id}` so
+URLs to that section stay stable even if the heading text changes:
+
+```md
+## My new section {#my-new-section}
+```
+
+**Use sentence case for headings.** Write "Getting started" not
+"Getting Started".
+
+**Keep the heading hierarchy consistent.** Pages use H2 (`##`) for top-level
+sections and H3 (`###`) for subsections. Don't skip levels.
+
+**Update the page if there's a table of contents or "On this page" intro.**
+Some pages have an introductory list of topics — add your section there too.
+
+## Type 4: Adding a new page {#new-page}
+
+1. Create the MDX file in the appropriate `docs/` subdirectory.
+   Every file must start with frontmatter:
+
+   ```
+   ---
+   title: 'Your Page Title'
+   ---
+   ```
+
+2. Add your page to the navigation in the
+   `docs.json` file in `bazel-contrib/bazel-docs`. Open an issue or ask a
+   maintainer to add your page to the nav — you don't need to do this yourself
+   for an initial PR.
+
+3. Follow the same branch, commit, and PR steps as Type 2.
+
+## MDX basics for doc contributors {#mdx-basics}
+
+MDX is mostly standard Markdown with a few differences.
+
+### Self-closing HTML tags {#self-closing-tags}
+
+JSX requires void elements to be self-closing. Use `<img ... />` and
+`<br />`, not `<img ...>` or `<br>`.
+
+### Links {#links}
+
+Use root-relative paths for internal links. Don't include the `.mdx` extension in the links:
+
+```md
+[labels](/concepts/labels)
+[style guide](/contribute/docs-style-guide)
+```
+
+### Code blocks {#code-blocks}
+
+Always specify a language for syntax highlighting:
+
+````md
+```bash
+bazel build //my/example:app
+```
+````
+
+Common languages used in Bazel docs: `bash`, `python`, `starlark`, `json`,
+`posix-terminal`.
+
+### Images {#images}
+
+Place images in the `images/` subdirectory alongside your MDX file and
+reference them with a root-relative path:
+
+```md
+![Alt text](/contribute/images/my-diagram.png)
+```
+
+Use self-closing syntax: Markdown image syntax does not require the trailing `/>`, 
+but `<img>` tags must self-close when you use them directly:
+
+```md
+<img src="/contribute/images/my-diagram.png" alt="Alt text" width="400" />
+```
+
+### Notes and callouts {#callouts}
+
+Mintlify supports callout components. Use them for important warnings or tips:
+
+```md
+<Note>
+This is a note.
+</Note>
+
+<Warning>
+This is a warning.
+</Warning>
+```
+
+## What to expect after submitting {#after-submitting}
+
+- The Google CLA bot checks that you've signed the
+  [Contributor License Agreement](https://cla.developers.google.com/). You
+  only need to do this once.
+- CI runs a docs validation check.
+- A maintainer reviews your PR and might make requests for edits. Response times vary.
+- Once approved, your changes are merged to `master` and appear on the
+  live site after the next sync.
+
+## Getting help {#getting-help}
+
+- File an issue in [`bazelbuild/bazel`](https://github.com/bazelbuild/bazel/issues)
+  with the label `type: documentation`.
+- For questions about the docs platform, open an
+  issue in [`bazel-contrib/bazel-docs`](https://github.com/bazel-contrib/bazel-docs/issues).

release/index.mdx

@@ -15,7 +15,7 @@ information about Bazel's release model.
 | ----------- | ------------- | -------------- | -------------- |
 | Bazel 10 | Rolling| [Check rolling release page](/release/rolling) | N/A |
 | Bazel 9 | Active| [9.1.0](https://github.com/bazelbuild/bazel/releases/tag/9.1.0) | Dec 2028 |
-| Bazel 8 | Maintenance| [8.7.0](https://github.com/bazelbuild/bazel/releases/tag/8.7.0) | Dec 2027 |
+| Bazel 8 | Maintenance| [8.6.0](https://github.com/bazelbuild/bazel/releases/tag/8.6.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 |
 | Bazel 5 | Deprecated | [5.4.1](https://github.com/bazelbuild/bazel/releases/tag/5.4.1) | Jan 2025 |

rules/lib/builtins/ToolchainContext.mdx

@@ -2,16 +2,4 @@
 title: 'ToolchainContext'
 ---
 
-Holds toolchains available for a particular exec group. Toolchain targets are accessed by indexing with the toolchain type, as in `ctx.toolchains["//pkg:my_toolchain_type"]`. If the toolchain was optional and no toolchain was resolved, this will return `None`. Accessing toolchains of an aspect or rule via `ctx.toolchains` returns the indexed toolchain as a `ToolchainInfo` provider. While when using aspects, `ToolchainContext` is also used to hold the toolchains of the base target. It can be accessed by `ctx.rule.toolchains["//pkg:my_toolchain_type"]` and it returns the list of providers resulted from applying the aspects on these toolchain targets.
-
-## Members
-
-* [toolchain_types](#toolchain_types)
-
-## toolchain_types
-
-```
-sequence ToolchainContext.toolchain_types()
-```
-
-Returns the resolved toolchain type labels.
+Holds toolchains available for a particular exec group. Toolchain targets are accessed by indexing with the toolchain type, as in `ctx.toolchains["//pkg:my_toolchain_type"]`. If the toolchain was optional and no toolchain was resolved, this will return `None`. Accessing toolchains of an aspect or rule via `ctx.toolchains` returns the indexed toolchain as a `ToolchainInfo` provider. While when using aspects, `ToolchainContext` is also used to hold the toolchains of the base target. It can be accessed by `ctx.rule.toolchains["//pkg:my_toolchain_type"]` and it returns the list of providers resulted from applying the aspects on these toolchain targets.