Fix broken links (#1583)

Author: mthalman

Diff for: documentation/base-image-dependency-flow.md

@@ -7,7 +7,7 @@ The first step is to make sure that we can easily determine which version of the
 
 When an image is built, the value of its base image's digest is stored in what's called an image info file.  This JSON file contains useful metadata about images that can be easily consumed by the engineering system.  When running a build, there are several build jobs running in parallel building different images for different platforms and architectures.  Each of these build jobs are producing an image info file that contains metadata about the images that were built by that specific build job.
 
-Once all the build jobs have finished, another task collects all the image info files produced by the jobs and merges them into a single image info file.  After the images have been published to [MCR](https://azure.microsoft.com/blog/microsoft-syndicates-container-catalog/), the contents of this image info file are merged into the main [image info](https://github.com/dotnet/versions/blob/main/build-info/docker/image-info.json) file in GitHub.
+Once all the build jobs have finished, another task collects all the image info files produced by the jobs and merges them into a single image info file.  After the images have been published to [MCR](https://azure.microsoft.com/blog/microsoft-syndicates-container-catalog/), the contents of this image info file are merged into the main [image info](https://github.com/dotnet/versions/blob/main/build-info/docker/image-info.dotnet-dotnet-docker-main.json) file in GitHub.
 
 At this point, we've got a persistent record of the base image versions that each of the published .NET Docker images are dependent upon.  This is useful information to have in general.  For example, it can used when troubleshooting an issue of a .NET Docker image and it's necessary to know what specific version of its base image was being used.  But for this particular automated system, it'll be used to determine whether an image has been updated or not, which is described next.
 
@@ -18,7 +18,7 @@ Another part of the automation is an Azure DevOps pipeline that will check wheth
 For each subscription described in the subscriptions file, the pipeline runs the following process:
 1. Loads the manifest and Dockerfile from the subscribed repo.  The manifest contains metadata about all the images that are to be produced for the repo, how they are to be tagged, and a bunch of other information.  This file, when paired with the content of the repo's Dockerfiles, provides an easily consumable description of the base image tags that are being depended upon.
 2. Now that we've got the list of base image tags that we care about, the pipeline makes use of the Docker Registry to get the latest digest values for those tags.
-3. Remember that [image info](https://github.com/dotnet/versions/blob/main/build-info/docker/image-info.json) file described above?  This is where it comes in handy.  The pipeline reads that file to determine which digests the published images are dependent upon and compares them to the latest digests that were retrieved in the previous step.  If those values are different, it means the published image is making use of an older version of the image.  We need to get it updated!  The pipeline keeps track of which images, and their dependent images, need to be rebuilt.
+3. Remember that [image info](https://github.com/dotnet/versions/blob/main/build-info/docker/image-info.dotnet-dotnet-docker-main.json) file described above?  This is where it comes in handy.  The pipeline reads that file to determine which digests the published images are dependent upon and compares them to the latest digests that were retrieved in the previous step.  If those values are different, it means the published image is making use of an older version of the image.  We need to get it updated!  The pipeline keeps track of which images, and their dependent images, need to be rebuilt.
 4. If any images need to be rebuilt, the pipeline constructs a special build argument that describes the set of paths to the Dockerfiles that need to be built.  It then queues a build for the pipeline referenced by the subscription in the subscriptions file, passing it this build argument.  When that pipeline builds the images, it will ensure that the built images are making use of the latest base images, just by the nature of the build process pulling the base image before building.  You can see here that there's a virtuous cycle; when the pipeline publishes these updated images, it updates the main image info so that it now references the latest base image digests.  That is, until the next base image changes and the process starts all over again.
 
 This entire process is hands-off automation running 7 days a week, allowing consumers of .NET Docker images to be assured they're getting the most up-to-date version of the images they care about.