Fix Markdown portability issues
When trying to change the Markdown engine, I've spotted a few differences.
This should make the code more portable.
RELNOTES: None.
PiperOrigin-RevId: 220446625
diff --git a/site/docs/configurable-attributes.md b/site/docs/configurable-attributes.md
index 8dcb0fd..e54dd60 100644
--- a/site/docs/configurable-attributes.md
+++ b/site/docs/configurable-attributes.md
@@ -24,8 +24,8 @@
-**_Configurable attributes_**, commonly known as [`select()`]
-(be/functions.html#select), is a Bazel feature that lets users toggle the values
+**_Configurable attributes_**, commonly known as [`select()`](
+be/functions.html#select), is a Bazel feature that lets users toggle the values
of BUILD rule attributes at the command line.
This can be used, for example, for a multiplatform library that automatically
@@ -196,8 +196,8 @@
of custom conditioning it can support is limited. For example, there's no Bazel
flag for `IncludeSpecialProjectFeatureX`.
-Plans for [truly custom flags]
-(https://docs.google.com/document/d/1vc8v-kXjvgZOdQdnxPTaV0rrLxtP2XwnD2tAZlYJOqw/edit?usp=sharing)
+Plans for [truly custom flags](
+https://docs.google.com/document/d/1vc8v-kXjvgZOdQdnxPTaV0rrLxtP2XwnD2tAZlYJOqw/edit?usp=sharing)
are underway. In the meantime, [`--define`](user-manual.html#flag--define) is
the best approach for these purposes.
`--define` is a bit awkward to use and wasn't originally designed for this
@@ -319,9 +319,9 @@
bazel build //my_app:my_rocks --define color=white --define texture=smooth --define type=metamorphic
```
-Platforms are still under development. See the [documentation]
-(https://docs.bazel.build/versions/master/platforms.html) and [roadmap]
-(https://bazel.build/roadmaps/platforms.html) for details.
+Platforms are still under development. See the [documentation](
+https://docs.bazel.build/versions/master/platforms.html) and
+[roadmap](https://bazel.build/roadmaps/platforms.html) for details.
## Short Keys
@@ -506,8 +506,8 @@
duplication.
`select()` doesn't support native syntax for `OR`ed conditions. For this, use
-the [Skylib](https://github.com/bazelbuild/bazel-skylib) utility [`selects`]
-(https://github.com/bazelbuild/bazel-skylib/blob/master/lib/selects.bzl).
+the [Skylib](https://github.com/bazelbuild/bazel-skylib) utility [`selects`](
+https://github.com/bazelbuild/bazel-skylib/blob/master/lib/selects.bzl).
```python
load("@bazel_skylib//:lib.bzl", "selects")
@@ -600,8 +600,8 @@
This is for two reasons.
First, macros that need to know which path a `select` will choose *cannot work*
-because macros are evaluated in Bazel's [loading phase]
-(user-manual.html#loading-phase), which occurs before flag values are known.
+because macros are evaluated in Bazel's [loading phase](user-manual.html#loading-phase),
+which occurs before flag values are known.
This is a core Bazel design restriction that's unlikely to change any time soon.
Second, macros that just need to iterate over *all* `select` paths, while
@@ -609,8 +609,8 @@
this.
## <a name="query"></a>Bazel Query and Cquery
-Bazel `query` operates over Bazel's [loading phase]
-(user-manual.html#loading-phase). This means it doesn't know what command line
+Bazel `query` operates over Bazel's [loading phase](
+user-manual.html#loading-phase). This means it doesn't know what command line
flags will be applied to a target since those flags aren't evaluated until later
in the build (during the [analysis phase](user-manual.html#analysis-phase)). So
the [`query`](query.html) command can't accurately determine which path a
diff --git a/site/docs/remote-caching.md b/site/docs/remote-caching.md
index 35b6ca7..8cafd79 100644
--- a/site/docs/remote-caching.md
+++ b/site/docs/remote-caching.md
@@ -379,8 +379,8 @@
* **Faster Bazel builds with remote caching: a benchmark:** Nicolò Valigi wrote a [blog post](https://nicolovaligi.com/faster-bazel-remote-caching-benchmark.html) in which he benchmarks remote caching in Bazel.
-[Adapting Rules for Remote Execution](https://docs.bazel.build/versions/master/remote-execution-rules.html)
-[Troubleshooting Remote Execution](https://docs.bazel.build/versions/master/remote-execution-sandbox.html)
+[Adapting Rules for Remote Execution]: https://docs.bazel.build/versions/master/remote-execution-rules.html
+[Troubleshooting Remote Execution]: https://docs.bazel.build/versions/master/remote-execution-sandbox.html
[WebDAV module]: http://nginx.org/en/docs/http/ngx_http_dav_module.html
[docker image]: https://hub.docker.com/r/buchgr/bazel-remote-cache/
[GitHub]: https://github.com/buchgr/bazel-remote/
diff --git a/site/docs/skylark/aspects.md b/site/docs/skylark/aspects.md
index 4558004..6511dc6 100644
--- a/site/docs/skylark/aspects.md
+++ b/site/docs/skylark/aspects.md
@@ -122,7 +122,6 @@
### Aspect implementation
```python
-
def _print_aspect_impl(target, ctx):
# Make sure the rule has a srcs attribute.
if hasattr(ctx.rule.attr, 'srcs'):
diff --git a/site/docs/tutorial/java.md b/site/docs/tutorial/java.md
index 0ffcef9..b0ee64f 100644
--- a/site/docs/tutorial/java.md
+++ b/site/docs/tutorial/java.md
@@ -263,8 +263,8 @@
Looking at the dependency graph, you can see that `ProjectRunner` depends on the
same inputs as it did before, but the structure of the build is different:
-![Dependency graph of the target 'ProjectRunner' after adding a dependency]
-(/assets/tutorial_java_02.svg)
+
You've now built the project with two targets. The `ProjectRunner` target builds
two source files and depends on one other target (`:greeter`), which builds
