Fix more broken links

.github/ISSUE_TEMPLATE/new-windows-release.md

@@ -36,4 +36,4 @@ Windows version: <version>
 
 ## Nightly Branch Tasks
 
-- [ ] Merge these changes to the nightly branch as part of the nightly branch [release process](dotnet-release.md) for the next .NET release.
+- [ ] Merge these changes to the nightly branch as part of the nightly branch [release process](releases/dotnet-release-lifecycle.md) for the next .NET release.

.github/linters/.check-markdown-links.json

@@ -1,7 +1,7 @@
 {
     "ignorePatterns": [
         {
-            "pattern": "^https://dev.azure.com/dnceng/internal/_build?definitionId=359"
+            "pattern": "^https://dev.azure.com/dnceng/internal/_build\\?definitionId=359"
         },
         {
             "pattern": "^https://github.com/dotnet/release/blob/main/.github/ISSUE_TEMPLATE/dotnet-docker-servicing-release.md"
@@ -10,10 +10,13 @@
             "pattern": "^https://security.alpinelinux.org"
         },
         {
-            "pattern": "^https://security-tracker.debian.org/tracker"
+            "pattern": "^l-is-the-package-in-the-linux-distro-base-image"
         },
         {
-            "pattern": "^https://security-tracker.debian.org/tracker/CVE-2022-42898"
+            "pattern": "^https://mcr.microsoft.com/v2/\\{\\{REPO\\}\\}/tags/list"
+        },
+        {
+            "pattern": "^https://github.com/dotnet/dotnet-docker/blob/\\{\\{if"
         }
     ]
-}
+}

documentation/scenarios/installing-dotnet.md

@@ -8,7 +8,7 @@ There are two scenarios you should consider depending on how your Docker image i
 
 Before doing all the work of authoring and maintaining a Dockerfile that installs .NET, it's worthwhile to stop and thoroughly analyze whether you actually do need a different base image than those provided as part of the set of official [.NET Docker images](https://hub.docker.com/r/microsoft/dotnet).
 
-If there's a platform that you require that is available in its own Docker image, ask yourself whether it would be better to use that image and add .NET to it or would it be better to use the .NET image as the base and add the platform to it. An example scenario is using the .NET runtime with PowerShell Core; determine whether you would prefer to start with a [PowerShell Core](https://hub.docker.com/r/microsoft/powershell) image and install .NET runtime onto it or start with a [.NET runtime image](https://hub.docker.com/r/microsoft/dotnet-runtime) and install PowerShell Core onto it.
+If there's a platform that you require that is available in its own Docker image, ask yourself whether it would be better to use that image and add .NET to it or would it be better to use the .NET image as the base and add the platform to it. An example scenario is using the .NET runtime with PowerShell; determine whether you would prefer to start with a [PowerShell](https://mcr.microsoft.com/product/powershell/about) image and install .NET runtime onto it or start with a [.NET runtime image](https://hub.docker.com/r/microsoft/dotnet-runtime) and install PowerShell Core onto it.
 
 In some cases, you can workaround dependencies by publishing your .NET application as a [self-contained app](https://docs.microsoft.com/en-us/dotnet/core/deploying) in which case all of your app's dependencies are packaged with the app. This reduces the dependencies that need to be installed separately on the base image. For example, a Windows app may require dependencies that only exist in Windows Server Core but only .NET (pre-5.0) images on Nano Server are available. In that case, the app could be deployed as a self-contained app and operate just fine using the [windows/servercore](https://hub.docker.com/r/microsoft/windows-servercore) image as the base image. Example Dockerfiles that demonstrate publishing a self-contained app are available in the samples for [Linux](https://github.com/dotnet/dotnet-docker/blob/main/samples/dotnetapp/Dockerfile.debian) and [Windows](https://github.com/dotnet/dotnet-docker/blob/main/samples/dotnetapp/Dockerfile.nanoserver).
 

samples/build-for-a-platform.md

@@ -62,8 +62,8 @@ Another approach is to always build for one platform with Dockerfiles that refer
 
 The following are examples of this model:
 
-- [Dockerfile.debian-x64](aspnetapp/Dockerfile.debian-x64)
-- [Dockerfile.alpine-arm64](aspnetapp/Dockerfile.alpine-arm64)
+- [Dockerfile.debian](aspnetapp/Dockerfile.debian)
+- [Dockerfile.alpine](aspnetapp/Dockerfile.alpine)
 
 They can be built with the following pattern: