Merge pull request #14373 from samuelkarp/fix_links_workflow

docs: fix broken documentation links

.github/workflows/links.yml

@@ -26,7 +26,8 @@ jobs:
         with:
           # Fail action on broken links
           fail: true
-          args: --exclude-path vendor --exclude-path releases --timeout 30 --no-progress './**/*.md'
+          # Exclude core/runtime/v2/README.md symlink, already checked in docs/runtime-v2.md
+          args: --exclude-path vendor --exclude-path releases --exclude-path core/runtime/v2/README.md --timeout 30 --no-progress './**/*.md'
           format: markdown
           # Write GitHub job summary
           jobSummary: true

BUILDING.md

@@ -61,7 +61,7 @@ Runc is the default container runtime used by `containerd` and is required to
 run containerd. While it is okay to download a `runc` binary and install that on
 the system, sometimes it is necessary to build runc directly when working with
 container runtime development. Make sure to follow the guidelines for versioning
-in [RUNC.md](/docs/RUNC.md) for the best results.
+in [RUNC.md](docs/RUNC.md) for the best results.
 
 > *Note*: Runc only supports Linux
 
@@ -128,7 +128,7 @@ to use `go mod` command to modify the dependencies. After modifition, you should
 and `go mod vendor` to ensure the `go.mod`, `go.sum` files and `vendor` directory are up to date.
 Changes to these files should become a single commit for a PR which relies on vendored updates.
 
-Please refer to [RUNC.md](/docs/RUNC.md) for the currently supported version of `runc` that is used by containerd.
+Please refer to [RUNC.md](docs/RUNC.md) for the currently supported version of `runc` that is used by containerd.
 
 > *Note*: On macOS, the containerd daemon can be built and run natively. However, as stated above, runc only supports linux.
 

contrib/ansible/README.md

@@ -8,7 +8,7 @@ This document provides the steps to bring up a Kubernetes cluster using ansible
 - **Ansible**: 2.4+
 
 ## Step 0:
--  Install Ansible on the host where you will provision the cluster. This host may be one of the nodes you plan to include in your cluster. Installation instructions for Ansible are found [here](http://docs.ansible.com/ansible/latest/intro_installation.html).
+-  Install Ansible on the host where you will provision the cluster. This host may be one of the nodes you plan to include in your cluster. Installation instructions for Ansible are found in the [Ansible documentation](https://github.com/ansible/ansible#use-ansible).
 -  Create a hosts file and include the IP addresses of the hosts that need to be provisioned by Ansible.
 ```console
 $ cat hosts
@@ -29,7 +29,7 @@ A typical cloud login might have a username and private key file, in which case
 ```console
 ansible-playbook -i hosts -u <username> --private-key <example.pem> cri-containerd.yaml
  ```
-For more options ansible config file (/etc/ansible/ansible.cfg) can be used to set defaults. Please refer to [Ansible options](http://docs.ansible.com/ansible/latest/intro_configuration.html) for advanced ansible configurations.
+For more options ansible config file (/etc/ansible/ansible.cfg) can be used to set defaults. Please refer to the [Ansible documentation](https://github.com/ansible/ansible-documentation) for advanced ansible configurations.
 
 At the end of this step, you will have the required software installed in the hosts to bringup a kubernetes cluster.
 ```console

docs/containerd-2.0.md

@@ -113,7 +113,7 @@ The following syscalls (`io_uring_enter`, `io_uring_register`, and `io_uring_set
 
 Additional context:
 
-- <https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html>
+- [#9048](https://github.com/containerd/containerd/issues/9048)
 
 ### `LimitNOFILE` configuration has been removed
 

docs/cri/config.md

@@ -49,7 +49,7 @@ apiVersion: kubelet.config.k8s.io/v1beta1
 cgroupDriver: "systemd"
 ```
 
-kubeadm users should also see [the kubeadm documentation](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/).
+kubeadm users should also see [the kubeadm documentation](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configuring-a-cgroup-driver).
 
 > Note: Kubernetes v1.28 supports automatic detection of the cgroup driver as
 > an alpha feature. With the `KubeletCgroupDriverFromCRI` kubelet feature gate

docs/cri/crictl.md

@@ -12,7 +12,7 @@ or `crictl` please make sure the issue has not already been submitted.
 If you have not already installed crictl please install the version compatible
 with the `cri` plugin you are using. If you are a user, your deployment
 should have installed crictl for you. If not, get it from your release tarball.
-If you are a developer the current version of crictl is specified [here](/script/setup/critools-version).
+If you are a developer the current version of crictl is specified [here](../../script/setup/critools-version).
 A helper command has been included to install the dependencies at the right version:
 ```console
 $ make install-deps

docs/cri/registry.md

@@ -70,7 +70,7 @@ After modifying this config, you need to restart the `containerd` service.
 If you don't already have Google Container Registry (GCR) set up then you need to do the following steps:
 
 * Create a Google Cloud Platform (GCP) account and project if not already created (see [GCP getting started](https://cloud.google.com/gcp/getting-started))
-* Enable GCR for your project (see [Quickstart for Container Registry](https://cloud.google.com/container-registry/docs/quickstart))
+* Enable GCR for your project (see [Set up repositories with gcr.io domain support](https://cloud.google.com/artifact-registry/docs/transition/setup-gcr-repo))
 * For authentication to GCR: Create [service account and JSON key](https://cloud.google.com/container-registry/docs/advanced-authentication#json-key)
 * The JSON key file needs to be downloaded to your system from the GCP console
 * For access to the GCR storage: Add service account to the GCR storage bucket with storage admin access rights (see [Granting permissions](https://cloud.google.com/container-registry/docs/access-control#grant-bucket))

docs/features.md

@@ -120,7 +120,7 @@ status, err := task.Wait(context)
 
 ## Checkpoint and Restore
 
-If you have [criu](https://criu.org/Main_Page) installed on your machine you can checkpoint and restore containers and their tasks.  This allows you to clone and/or live migrate containers to other machines.
+If you have [criu](https://github.com/checkpoint-restore/criu) installed on your machine you can checkpoint and restore containers and their tasks.  This allows you to clone and/or live migrate containers to other machines.
 
 ```go
 // checkpoint the task then push it to a registry

docs/getting-started.md

@@ -103,7 +103,7 @@ The `containerd.io` package contains runc too, but does not contain CNI plugins.
 
 ### Option 3: From source
 
-To install containerd and its dependencies from the source, see [`BUILDING.md`](/BUILDING.md).
+To install containerd and its dependencies from the source, see [`BUILDING.md`](../BUILDING.md).
 
 ## Installing containerd on Windows
 
@@ -143,7 +143,7 @@ Start-Service containerd
 > **Tip for Running `containerd` Service on Windows:**
 >
 > `containerd` logs are not persisted when we start it as a service
-using Windows Service Manager. [`nssm`](https://nssm.cc) can be used to
+using Windows Service Manager. [`nssm`](https://github.com/kirillkovalenko/nssm) can be used to
 configure logs to go into a cyclic buffer:
 > ```powershell
 > nssm.exe install containerd
@@ -198,7 +198,7 @@ For non-managed environments, see the following Kubernetes documentations:
 ## Customizing containerd
 
 containerd uses a configuration file located in `/etc/containerd/config.toml` for specifying daemon level options.
-A sample configuration file can be found [here](/docs/man/containerd-config.toml.5.md).
+A sample configuration file can be found [here](man/containerd-config.toml.5.md).
 
 The default configuration can be generated via `containerd config default > /etc/containerd/config.toml`.
 

docs/snapshotters/devmapper.md

@@ -195,7 +195,7 @@ See also [Configure direct-lvm mode for production](https://docs.docker.com/stor
 
 For more information on Device-mapper, thin provisioning, etc., you can refer to the following resources:
 
-* https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/device_mapper
+* https://docs.kernel.org/admin-guide/device-mapper/index.html
 * https://en.wikipedia.org/wiki/Device_mapper
 * https://docs.docker.com/storage/storagedriver/device-mapper-driver/
 * https://www.kernel.org/doc/Documentation/device-mapper/thin-provisioning.txt

docs/snapshotters/remote-snapshotter.md

@@ -12,7 +12,7 @@ This enables containerd to lazily pull images from standard-compliant registries
 ## The containerd client API
 
 The containerd client's `Pull` API with unpacking-mode allows the underlying snapshotter to query for remote snapshots before fetching content.
-Remote snapshotter needs to be plugged into containerd in [the same ways as normal snapshotters](/docs/PLUGINS.md).
+Remote snapshotter needs to be plugged into containerd in [the same ways as normal snapshotters](../PLUGINS.md).
 
 ```go
 import (
@@ -87,7 +87,7 @@ if _, err := client.Pull(ctx, ref,
 
 The containerd client queries remote snapshots to the underlying remote snapshotter using snapshotter APIs.
 This section describes the high-level overview of how snapshotter APIs are used for remote snapshots functionality, with some piece of pseudo-codes that describe the simplified logic implemented in the containerd client.
-For more details, see [`unpacker.go`](../core/unpack/unpacker.go) that implements this logic.
+For more details, see [`unpacker.go`](../../core/unpack/unpacker.go) that implements this logic.
 
 During image pull, the containerd client calls `Prepare` API with the label `containerd.io/snapshot.ref`.
 This is a containerd-defined label which contains ChainID that targets a committed snapshot that the client is trying to prepare.