Bazel DocGen (2/3): Update templates to work with the new site.

This change fixes the layout by replacing the legacy Jekyll instructions with custom HTML code. Moreover, it updates links to point to the new site.

PiperOrigin-RevId: 433167785

CODEBASE.md

@@ -90,7 +90,7 @@ from the client are handled by `GrpcServerImpl.run()`.
 
 Bazel creates a somewhat complicated set of directories during a build. A full
 description is available
-[here](https://docs.bazel.build/versions/main/output_directories.html).
+[here](https://bazel.build/docs/output_directories).
 
 The "workspace" is the source tree Bazel is run in. It usually corresponds to
 something you checked out from source control.
@@ -194,7 +194,7 @@ Bazel learns about option classes in the following ways:
 3.  From `ConfiguredRuleClassProvider` (these are command line options related
     to individual programming languages)
 4.  Starlark rules can also define their own options (see
-    [here](https://docs.bazel.build/versions/main/skylark/config.html))
+    [here](https://bazel.build/rules/config))
 
 Each option (excluding Starlark-defined options) is a member variable of a
 `FragmentOptions` subclass that has the `@Option` annotation, which specifies
@@ -212,7 +212,7 @@ Bazel is in the business of building software, which happens by reading and
 interpreting the source code. The totality of the source code Bazel operates on
 is called "the workspace" and it is structured into repositories, packages and
 rules. A description of these concepts for the users of Bazel is available
-[here](https://docs.bazel.build/versions/main/build-ref.html).
+[here](https://bazel.build/concepts/build-ref).
 
 ### Repositories
 
@@ -431,10 +431,10 @@ Starlark is used in four contexts:
 
 The dialects available for BUILD and .bzl files are slightly different because
 they express different things. A list of differences is available
-[here](https://docs.bazel.build/versions/main/skylark/language.html#differences-between-build-and-bzl-files).
+[here](https://bazel.build/rules/language#differences-between-build-and-bzl-files).
 
 More information about Starlark is available
-[here](https://docs.bazel.build/versions/main/skylark/language.html).
+[here](https://bazel.build/rules/language).
 
 ## The loading/analysis phase
 
@@ -538,7 +538,7 @@ If a configuration transition results in multiple configurations, it's called a
 _split transition._
 
 Configuration transitions can also be implemented in Starlark (documentation
-[here](https://docs.bazel.build/versions/main/skylark/config.html))
+[here](https://bazel.build/rules/config))
 
 ### Transitive info providers
 
@@ -637,7 +637,7 @@ necessitates the following additional components:
 
 Aspects are a way to "propagate computation down the dependency graph". They are
 described for users of Bazel
-[here](https://docs.bazel.build/versions/main/skylark/aspects.html). A good
+[here](https://bazel.build/rules/aspects). A good
 motivating example is protocol buffers: a `proto_library` rule should not know
 about any particular language, but building the implementation of a protocol
 buffer message (the “basic unit” of protocol buffers) in any programming
@@ -688,7 +688,7 @@ Bazel supports multi-platform builds, that is, builds where there may be
 multiple architectures where build actions run and multiple architectures for
 which code is built. These architectures are referred to as _platforms_ in Bazel
 parlance (full documentation
-[here](https://docs.bazel.build/versions/main/platforms.html))
+[here](https://bazel.build/docs/platforms))
 
 A platform is described by a key-value mapping from _constraint settings_ (e.g.
 the concept of "CPU architecture") to _constraint values_ (e.g. a particular CPU
@@ -701,7 +701,7 @@ 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 platform
 (documentation for toolchains
-[here](https://docs.bazel.build/versions/main/toolchains.html)).
+[here](https://bazel.build/docs/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
@@ -838,7 +838,7 @@ _will_ come to depend on all parts of your code).
 Bazel supports this by the mechanism called _visibility: _you can declare that a
 particular rule can only be depended on using the visibility attribute
 (documentation
-[here](https://docs.bazel.build/versions/main/be/common-definitions.html#common-attributes)).
+[here](https://bazel.build/reference/be/common-definitions#common-attributes)).
 This attribute is a little special because unlike every other attribute, the set
 of dependencies it generates is not simply the set of labels listed (yes, this
 is a design flaw).
@@ -1093,7 +1093,7 @@ inputs reflects the result of input discovery and pruning done before.
 
 Starlark actions can make use of the facility to declare some inputs as unused
 using the `unused_inputs_list=` argument of
-<code>[ctx.actions.run()](https://docs.bazel.build/versions/main/skylark/lib/actions.html#run)</code>.
+<code>[ctx.actions.run()](https://bazel.build/rules/lib/actions#run)</code>.
 
 ### Various ways to run actions: Strategies/ActionContexts
 
@@ -1257,7 +1257,7 @@ runs the test in the requested way.
 Tests are run according to an elaborate protocol that uses environment variables
 to tell tests what's expected from them. A detailed description of what Bazel
 expects from tests and what tests can expect from Bazel is available
-[here](https://docs.bazel.build/versions/main/test-encyclopedia.html). At the
+[here](https://bazel.build/reference/test-encyclopedia). At the
 simplest, an exit code of 0 means success, anything else means failure.
 
 In addition to the cache status file, each test process emits a number of other
@@ -1370,7 +1370,7 @@ attribute of the first test that is executed.
 ## The query engine
 
 Bazel has a
-[little language](https://docs.bazel.build/versions/main/query-how-to.html)
+[little language](https://bazel.build/docs/query-how-to)
 used to ask it various things about various graphs. The following query kinds
 are provided:
 
@@ -1428,7 +1428,7 @@ interested in. For example, the following things are represented as events:
 *   A test was run (`TestAttempt`, `TestSummary`)
 
 Some of these events are represented outside of Bazel in the
-[Build Event Protocol](https://docs.bazel.build/versions/main/build-event-protocol.html)
+[Build Event Protocol](https://bazel.build/docs/build-event-protocol)
 (they are `BuildEvent`s). This allows not only `BlazeModule`s, but also things
 outside the Bazel process to observe the build. They are accessible either as a
 file that contains protocol messages or Bazel can connect to a server (called

site/command-line-reference-prefix.html

@@ -1,15 +1,11 @@
----
-layout: documentation
-title: Command-Line Reference
----
+<html devsite>
+<head>
+  <meta name="project_path" value="/_project.yaml">
+  <meta name="book_path" value="/_book.yaml">
+</head>
+<body>
 
-<div style="background-color: #EFCBCB; color: #AE2B2B;  border: 1px solid #AE2B2B; border-radius: 5px; border-left: 10px solid #AE2B2B; padding: 0.5em;">
-    <b>IMPORTANT:</b> The Bazel docs have moved! Please update your bookmark to <a href="https://bazel.build/reference/command-line-reference" style="color: #0000EE;">https://bazel.build/reference/command-line-reference</a>
-    <p/>
-    You can <a href="https://blog.bazel.build/2022/02/17/Launching-new-Bazel-site.html" style="color: #0000EE;">read about</a> the migration, and let us <a href="https://forms.gle/onkAkr2ZwBmcbWXj7" style="color: #0000EE;">know what you think</a>.
-    </div>
-
-<h1>Command-Line Reference</h1>
+<h1 class="page-title">Command-Line Reference</h1>
 
 <pre>
 bazel [&lt;startup options&gt;] &lt;command&gt; [&lt;args&gt;]

site/command-line-reference-suffix.html

@@ -1,3 +1,4 @@
 
 <br/><br/><br/><br/>
-
+</body>
+</html>

src/main/java/com/google/devtools/build/docgen/templates/attributes/common/compatible_with.html

@@ -1,5 +1,5 @@
-<p><code>List of <a href="../build-ref.html#labels">labels</a>; optional;
-  <a href="#configurable-attributes">nonconfigurable</a></code></p>
+<p><code>List of <a href="${link build-ref#labels}"><a>labels</a>
+; optional; <a href="#configurable-attributes">nonconfigurable</a></code></p>
 
 <p>
 The list of environments this target can be built for, in addition to

src/main/java/com/google/devtools/build/docgen/templates/attributes/common/exec_compatible_with.html

@@ -1,5 +1,5 @@
-<p>
-<code>List of <a href="../build-ref.html#labels">labels</a>; optional;
+<p><code>List of <a href="${link build-ref#labels}"><a>labels</a>
+; optional;
 <a href="#configurable-attributes">nonconfigurable</a></code>
 </p>
 
@@ -10,5 +10,5 @@
 addition to any constraints already set by the rule type. Constraints are used
 to restrict the list of available execution platforms. For more details, see
 the description of
-  <a href="../toolchains.html#toolchain-resolution">toolchain resolution</a>.
+  <a href="/docs/toolchains#toolchain-resolution">toolchain resolution</a>.
   </p>

src/main/java/com/google/devtools/build/docgen/templates/attributes/common/features.html

@@ -3,8 +3,8 @@
 <p>A feature is string tag that can be enabled or disabled on a target. The
   meaning of a feature depends on the rule itself.</p>
 
-<p>This <code>features</code> attribute is combined with the <a href="${link
-package}">package</a> level <code>features</code> attribute. For example, if
+<p>This <code>features</code> attribute is combined with the <a href="${link package}">
+package</a> level <code>features</code> attribute. For example, if
 the features ["a", "b"] are enabled on the package level, and a target's
 <code>features</code> attribute contains ["-a", "c"], the features enabled for the
 rule will be "b" and "c".

src/main/java/com/google/devtools/build/docgen/templates/attributes/common/restricted_to.html

@@ -1,4 +1,5 @@
-<p><code>List of <a href="../build-ref.html#labels">labels</a>; optional;
+<p><code>List of <a href="${link build-ref#labels}">labels</a>
+; optional;
   <a href="#configurable-attributes">nonconfigurable</a></code></p>
 
 <p>

src/main/java/com/google/devtools/build/docgen/templates/attributes/common/tags.html

@@ -8,7 +8,7 @@
   <i>Tags</i> on non-test targets are used to control sandboxed execution of
   <code>genrule</code>s and
 
-<a href="/versions/{{ site.version }}/skylark/index.html">Starlark</a>
+<a href="/rules/concepts">Starlark</a>
   actions, and for parsing by humans and/or external tools.
 </p>
 
@@ -110,5 +110,6 @@
   </li>
 </ul>
 
-See <a href="../test-encyclopedia.html#tag-conventions">Tag Conventions</a> in the
-Test Encyclopedia for more conventions on tags attached to test targets.
+See
+<a href="${link test-encyclopedia#tag-conventions}">Tag Conventions</a>
+ in the Test Encyclopedia for more conventions on tags attached to test targets.

src/main/java/com/google/devtools/build/docgen/templates/attributes/common/target_compatible_with.html

@@ -1,5 +1,6 @@
 <p>
-<code>List of <a href="../build-ref.html#labels">labels</a>; optional</code>
+<code>List of <a href="${link build-ref#labels}">labels</a>
+; optional</code>
 </p>
 
 <p>
@@ -35,6 +36,6 @@
 
 <p>
 See the
-<a href="../platforms.html#skipping-incompatible-targets">Platforms</a>
+<a href="/docs/platforms#skipping-incompatible-targets">Platforms</a>
 page for more information about incompatible target skipping.
 </p>

src/main/java/com/google/devtools/build/docgen/templates/attributes/common/toolchains.html

@@ -1,4 +1,5 @@
-<p><code>List of <a href="../build-ref.html#labels">labels</a>; optional; <a href="#configurable-attributes">nonconfigurable</a></code></p>
+<p><code>List of <a href="${link build-ref#labels}"><a>labels</a>
+; optional; <a href="#configurable-attributes">nonconfigurable</a></code></p>
 
 <p>
   The set of targets whose <a href="${link make-variables}">Make variables</a> this target is
@@ -13,7 +14,7 @@
 
 <p>
   Note that this is distinct from the concept of
-    <a href="../toolchains.html#toolchain-resolution">toolchain resolution</a>
+    <a href="/docs/toolchains#toolchain-resolution">toolchain resolution</a>
     that is used by rule implementations for platform-dependent configuration. You cannot use this
   attribute to determine which specific <code>cc_toolchain</code> or <code>java_toolchain</code> a
   target will use.

src/main/java/com/google/devtools/build/docgen/templates/attributes/common/visibility.html

@@ -1,10 +1,11 @@
-<p><code>List of <a href="../build-ref.html#labels">labels</a>; optional;
+<p><code>List of <a href="${link build-ref#labels}"><a>labels</a>
+; optional;
 default <a href="${link package.default_visibility}">default_visibility</a> from
 <a href="${link package}">package</a> if specified, or //visibility:private
   otherwise; <a href="#configurable-attributes">nonconfigurable</a></code></p>
 
 <p>
 The <code>visibility</code> attribute on a target controls whether the target
 can be used in other packages. See the documentation for
-<a href="../visibility.md">visibility</a>.
+<a href="${link visibility}">visibility</a>.
 </p>

src/main/java/com/google/devtools/build/docgen/templates/attributes/test/env.html

@@ -12,12 +12,14 @@
 </p>
 
 <p>
+  This attribute only applies to native rules, like <code>cc_test</code>, <code>py_test</code>,
+  and <code>sh_test</code>.  It does not apply to Starlark-defined test rules.
   This attribute only applies to native rules, like <code>cc_test</code>,
   <code>py_test</code>, and <code>sh_test</code>. It does not apply to
   Starlark-defined test rules. For your own Starlark rules, you can add an "env"
   attribute and use it to populate a
 
-    <a href="../skylark/lib/testing.html#TestEnvironment">TestEnvironment</a>
+    <a href="/rules/lib/testing#TestEnvironment">TestEnvironment</a>
 
   Provider.
 </p>

src/main/java/com/google/devtools/build/docgen/templates/attributes/test/shard_count.html

@@ -8,13 +8,14 @@
 rules, this parameter may be required to enable sharding
 in the first place. Also see <code>--test_sharding_strategy</code>.</p>
 
-<p>If test sharding is enabled, the environment variable
-<a href="../test-encyclopedia.html#initial-conditions"><code>TEST_TOTAL_SHARDS</code></a>
-will be set to this value when spawning the test.</p>
+<p>If test sharding is enabled, the environment variable <code>
+<a href="${link test-encyclopedia#initial-conditions}">TEST_TOTAL_SHARDS</a>
+</code> will be set to this value when spawning the test.</p>
 
 <p>Sharding requires the test runner to support the test sharding protocol.
 If it does not, then it will most likely run every test in every shard, which
 is not what you want.</p>
 
-<p>See <a href="../test-encyclopedia.html#test-sharding">Test Sharding</a> in
-the Test Encyclopedia for details on sharding.</p>
+<p>See
+<a href="${link test-encyclopedia#initial-conditions}">Test Sharding</a>
+in the Test Encyclopedia for details on sharding.</p>

src/main/java/com/google/devtools/build/docgen/templates/attributes/test/size.html

@@ -45,7 +45,8 @@
   </tr>
 </table>
 
-<p>The environment variable
-<a href="../test-encyclopedia.html#initial-conditions"><code>TEST_SIZE</code></a> will be set to the
+<p>The environment variable <code>
+<a href="${link test-encyclopedia#initial-conditions}">TEST_SIZE</a>
+</code> will be set to the
 value of this attribute when spawning the test.</p>
 

src/main/java/com/google/devtools/build/docgen/templates/attributes/test/timeout.html

@@ -45,7 +45,7 @@
 timeout to two minutes.
 </p>
 
-<p>The environment variable
-<a href="../test-encyclopedia.html#initial-conditions"><code>TEST_TIMEOUT</code></a>
-will be set to the test timeout (in seconds) when spawning the test.</p>
+<p>The environment variable <code>
+<a href="${link test-encyclopedia#initial-conditions}">TEST_TIMEOUT</a>
+</code> will be set to the test timeout (in seconds) when spawning the test.</p>
 

src/main/java/com/google/devtools/build/docgen/templates/attributes/typical/data.html

@@ -1,5 +1,6 @@
 <a name="common.data"></a>
-<p><code>List of <a href="../build-ref.html#labels">labels</a>; optional</code></p>
+<p><code>List of <a href="${link build-ref#labels}">labels</a>
+; optional</code></p>
 
 <p>
 Files needed by this rule at runtime. May list file or rule targets. Generally
@@ -12,14 +13,14 @@
 output by or has a runtime dependency on this target. This may include data
 files or binaries used when this target's
 <a href="#typical.srcs"><code>srcs</code></a> are executed. See the
-<a href="../build-ref.html#data">data dependencies</a> section for more
-information about how to depend on and use data files.
+<a href="${link build-ref#data}">data dependencies</a>
+section for more information about how to depend on and use data files.
 </p>
 
 <p>
 New rules should define a <code>data</code> attribute if they process
 inputs which might use other inputs at runtime. Rules' implementation functions
-must also <a href="https://docs.bazel.build/versions/main/skylark/rules.html#runfiles">populate the target's
+must also <a href="https://bazel.build/rules/rules#runfiles">populate the target's
 runfiles</a> from the outputs and runfiles of any <code>data</code> attribute,
 as well as runfiles from any dependency attribute which provides either
 source code or runtime dependencies.

src/main/java/com/google/devtools/build/docgen/templates/attributes/typical/deps.html

@@ -1,5 +1,6 @@
 <a name="common.deps"></a>
-<p><code>List of <a href="../build-ref.html#labels">labels</a>; optional</code></p>
+<p><code>List of <a href="${link build-ref#labels}">labels</a>
+; optional</code></p>
 
 <p>
 Dependencies for this target. Generally should only list rule targets. (Though
@@ -9,8 +10,9 @@
 
 <p>
 Language-specific rules generally limit the listed targets to those with
-specific <a href="../skylark/rules.html#providers">providers</a>.
-</p>
+specific
+<a href="/rules/rules#providers">providers</a>
+.</p>
 
 <p>
 The precise semantics of what it means for a target to depend on another using
@@ -27,5 +29,6 @@
 cases: For example, a <code>java_library</code> target may depend on C++ code
 in a <code>cc_library</code> target, by listing the latter in the
 <code>deps</code> attribute.  See the definition of
-<a href="../build-ref.html#deps">dependencies</a> for more information.
+<a href="${link build-ref#deps}">dependencies</a>
+for more information.
 </p>

src/main/java/com/google/devtools/build/docgen/templates/attributes/typical/srcs.html

@@ -1,5 +1,5 @@
-<p><code>List of <a href="../build-ref.html#labels">labels</a>;
-  optional</code></p>
+<p><code>List of <a href="${link build-ref#labels}">labels</a>
+; optional</code></p>
 
 <p>
 Files processed or included by this rule. Generally lists files directly, but

src/main/java/com/google/devtools/build/docgen/templates/be/be-nav.vm

@@ -1,4 +1,4 @@
-#set ($path = "/versions/{{ site.version }}/be")
+#set ($path = "/reference/be")
 #set ($bazelbuildGithub = "https://github.com/bazelbuild")
 
 **Build Encyclopedia**