Fix Workflow Broken Markdown Links (dotnet#110332)

ivdiazsa · web-flow · commit 2b679cf05075 · 2024-12-03T10:20:36.000-08:00
* Fix Markdown links that broke after the workflow documentation reconsolidation.

* Fixed two other links that broke outside the workflow documents.

* Changed 'Debian/Ubuntu' to 'Debian and Ubuntu' in the Linux requirements doc because otherwise, I couldn't get the table of contents link to work correctly.
diff --git a/docs/design/features/y2038.md b/docs/design/features/y2038.md
@@ -22,7 +22,7 @@ Normally, ABI breaks like this are not a problem for the Linux ecosystem because
 
 ### .NET builds
 
-.NET official builds are produced by building the product on a [dedicated set of build images](https://github.com/dotnet/runtime/blob/main/docs/workflow/building/coreclr/linux-instructions.md). The images run Azure Linux 3.0 with an up-to-date cross-compilation toolchain, and also include a root filesystem of an old Linux distribution that provides an old version of glibc (or musl libc), which determines the libc compatibility of our builds.
+.NET official builds are produced by building the product on a [dedicated set of build images](https://github.com/dotnet/runtime/blob/main/docs/workflow/using-docker.md#the-official-runtime-docker-images). The images run Azure Linux 3.0 with an up-to-date cross-compilation toolchain, and also include a root filesystem of an old Linux distribution that provides an old version of glibc (or musl libc), which determines the libc compatibility of our builds.
 
 In .NET 8, we [support](https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md#libc-compatibility) glibc 2.23 and musl 1.2.2, by building the product with a root filesystem from Ubuntu 16.04 and Alpine 3.13, respectively.
 
diff --git a/docs/workflow/building/coreclr/README.md b/docs/workflow/building/coreclr/README.md
@@ -3,7 +3,7 @@
 - [The Basics](#the-basics)
   - [Build Results](#build-results)
   - [What to do with the Build](#what-to-do-with-the-build)
-    - [The Core_Root for Testing Your Build](#the-core-root-for-testing-your-build)
+    - [The Core_Root for Testing Your Build](#the-core\_root-for-testing-your-build)
     - [The Dev Shipping Packs](#the-dev-shipping-packs)
   - [Cross Compilation](#cross-compilation)
 - [Other Features](#other-features)
diff --git a/docs/workflow/building/coreclr/cross-building.md b/docs/workflow/building/coreclr/cross-building.md
@@ -146,7 +146,7 @@ When it comes to building, Docker offers the most flexibility when it comes to t
 
 ### Cross-Compiling for ARM32 and ARM64 with Docker
 
-As mentioned in the [Linux Cross-Building section](#linux-cross-building), the `ROOTFS_DIR` environment variable has to be set to the _crossrootfs_ location. The prereqs Docker images already have _crossrootfs_ built, so you only need to specify it when creating the Docker container by means of the `-e` flag. These locations are specified in the [Docker Images table](/docs/workflow/building/coreclr/linux-instructions.md#docker-images).
+As mentioned in the [Linux Cross-Building section](#linux-cross-building), the `ROOTFS_DIR` environment variable has to be set to the _crossrootfs_ location. The prereqs Docker images already have _crossrootfs_ built, so you only need to specify it when creating the Docker container by means of the `-e` flag. These locations are specified in the [Docker Images table](/docs/workflow/using-docker.md#the-official-runtime-docker-images).
 
 In addition, you also have to specify the `--cross` flag with the target architecture. For example, the following command would create a container to build CoreCLR for Linux ARM64:
 
diff --git a/docs/workflow/requirements/linux-requirements.md b/docs/workflow/requirements/linux-requirements.md
@@ -1,7 +1,7 @@
 # Requirements to Set Up the Build Environment on Linux
 
 - [Using your Linux Environment](#using-your-linux-environment)
-  - [Debian/Ubuntu](#debian/ubuntu)
+  - [Debian and Ubuntu](#debian-and-ubuntu)
     - [CMake on Older Versions of Ubuntu and Debian](#cmake-on-older-versions-of-ubuntu-and-debian)
     - [Clang for WASM](#clang-for-wasm)
     - [Additional Tools for Cross Building](#additional-tools-for-cross-building)
@@ -28,7 +28,7 @@ eng/common/native/install-dependencies.sh
 
 Note that it is always a good idea to manually double check that all the dependencies were installed correctly if you opt to use the script.
 
-### Debian/Ubuntu
+### Debian and Ubuntu
 
 These instructions are written assuming the current *Ubuntu LTS*.
 
diff --git a/docs/workflow/testing/coreclr/testing.md b/docs/workflow/testing/coreclr/testing.md
@@ -24,13 +24,12 @@ This guide will walk you through building and running the CoreCLR tests. These a
 
 ## Requirements
 
-In order to build CoreCLR tests, you will need to have built the runtime and the libraries (that is, _clr_ and _libs_ subsets). You can find more detailed instructions per platform in their dedicated docs:
+In order to build CoreCLR tests, you will need to have built the runtime and the libraries (that is, _clr_ and _libs_ subsets). You can find detailed instructions on how to do it on their respective README's:
 
-* [Windows](/docs/workflow/building/coreclr/windows-instructions.md)
-* [macOS](/docs/workflow/building/coreclr/macos-instructions.md)
-* [Linux](/docs/workflow/building/coreclr/linux-instructions.md)
+* [CoreCLR](/docs/workflow/building/coreclr/README.md)
+* [Libraries](/docs/workflow/building/libraries/README.md)
 
-For CoreCLR testing purposes, it is more than enough to simply build the _libs_ subset, as far as it concerns the libraries. If you want to know more in-depth about them, they have their own [libraries dedicated docs section](/docs/workflow/building/libraries/README.md).
+For CoreCLR testing purposes, it is more than enough to simply build the _libs_ subset, as far as it concerns the libraries. If you want to know more in-depth about them, they have their own [libraries dedicated docs section](/docs/workflow/building/libraries/).
 
 ## Overview
 
diff --git a/docs/workflow/testing/coreclr/unix-test-instructions.md b/docs/workflow/testing/coreclr/unix-test-instructions.md
@@ -6,7 +6,7 @@ CoreCLR tests
 
 ## Building
 
-Build CoreCLR on [Unix](../../building/coreclr/linux-instructions.md).
+Build CoreCLR following the instructions in its [main doc](/docs/workflow/building/coreclr/README.md).
 
 ## Building the Tests
 
diff --git a/docs/workflow/testing/libraries/testing.md b/docs/workflow/testing/libraries/testing.md
@@ -79,8 +79,7 @@ cd src\libraries\System.Collections.Immutable\tests
 dotnet build /t:Test
 ```
 
-**NOTE**: if your environment doesn't have the required SDK installed (e.g. inside [Docker container](/docs/workflow/building/coreclr/linux-instructions.md#build-using-docker)),
-use `./dotnet.sh`/`.\dotnet.cmd` instead of `dotnet`.
+**NOTE**: if your environment doesn't have the required SDK installed (e.g. inside [a Docker container](/docs/workflow/using-docker.md)), use `./dotnet.sh`/`.\dotnet.cmd` instead of `dotnet`.
 
 ### Running only certain tests
 
diff --git a/src/coreclr/nativeaot/docs/containers.md b/src/coreclr/nativeaot/docs/containers.md
@@ -14,7 +14,7 @@ The [`releasesapi`](https://github.com/dotnet/dotnet-docker/blob/main/samples/re
 
 For cloud native apps, build and runtime OS typically match, at least if you use multi-stage build. Once you step out of containers (for app delivery), it is more likely that you are delivering binaries that you want to work in more places (like on older Linux distros).
 
-The .NET build has this exact same need. We produce several [container images to enable cross-building](https://github.com/dotnet/runtime/blob/main/docs/workflow/building/coreclr/linux-instructions.md#docker-images).
+The .NET build has this exact same need. We produce several [container images to enable cross-building](https://github.com/dotnet/runtime/blob/main/docs/workflow/using-docker.md#the-official-runtime-docker-images).
 
 You can use these images to build native AOT apps which work on distros as old as Ubuntu 16.04. These build images are not supported, but are expected to work (since we use them to build .NET on daily basis).
 
