Merge pull request #1167 from wallrj/link-check

Run the link check for PRs and changes to master

.github/workflows/check.yaml

@@ -14,3 +14,13 @@ jobs:
           cache: npm
       - run: npm ci
       - run: npm run lint
+  link-check:
+    runs-on: ubuntu-22.04
+    steps:
+      - uses: actions/checkout@v3
+      - uses: actions/setup-node@v3
+        with:
+          node-version: 16
+          cache: npm
+      - run: npm ci
+      - run: npm run markdown-link-check

README.md

@@ -140,7 +140,7 @@ should be snappy to use.
 ### Running Verification Scripts
 
 After you have made changes to the website, you should run the `verify` scripts
-to ensure things like spelling and links are valid.
+to ensure things like spelling are valid.
 
 To run all verification checks:
 
@@ -153,6 +153,22 @@ This will automatically run a number of checks against your local environment.
 If you want to be thorough, you can run `./scripts/verify-release` to also regenerate API / CLI docs
 before verification, but that check is slower and unlikely to provide any useful insight.
 
+To run quick lint checks on the nextjs code, run [next lint](https://nextjs.org/docs/basic-features/eslint):
+
+```bash
+npm run lint
+```
+
+To check the links in all pages, run [markdown-link-check](https://github.com/tcort/markdown-link-check):
+
+```bash
+npm run markdown-link-check
+```
+
+> ℹ️ All these checks are also run automatically for pull requests.
+> The results will be reported in the [checks summary](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks) at the bottom of your GitHub PR.
+> Read the [cert-manager-website-presubmits.yaml prow configuration file](https://github.com/jetstack/testing/blob/master/config/jobs/cert-manager/website/cert-manager-website-presubmits.yaml) and the [check.yaml workflow file](.github/workflows/check.yaml) for more details.
+
 ### Building for a Release
 
 On release, all output is placed into the `out/` directory.

content/docs/concepts/issuer.md

@@ -41,4 +41,4 @@ can be used to issue `Certificates` across all namespaces.
 
 cert-manager supports a number of 'in-tree', as well as 'out-of-tree' `Issuer`
 types. An exhaustive list of these `Issuer` types can be found in the
-cert-manager [configuration documentation](../configuration.md).
+cert-manager [configuration documentation](../configuration/README.md).

content/docs/concepts/webhook.md

@@ -77,4 +77,4 @@ Or you could add a post-installation check which automatically retries the [Inst
 
 ### Other Webhook Problems
 
-If you encounter any other problems with the webhook, please refer to the [webhook troubleshooting guide](../troubleshooting/webhook/).
+If you encounter any other problems with the webhook, please refer to the [webhook troubleshooting guide](../troubleshooting/webhook.md).

content/docs/contributing/google-season-of-docs/2022/improve-navigation-and-structure.md

@@ -31,7 +31,7 @@ We set ourselves to rewrite this page with the goal of making it error-focused,
 meaning that the user would just be able to look for their particular error and
 start debugging it. We called it "The Definitive Debugging Guide for the
 cert-manager Webhook Pod", and it can be found
-[here](../../../troubleshooting/webhook/).
+[here](../../../troubleshooting/webhook.md).
 
 ### 12 Aug 2022: Improved the layout of the navigation menu
 

content/docs/installation/operator-lifecycle-manager.md

@@ -118,7 +118,7 @@ It will also be re-applied if OLM upgrades cert-manager.
 > 🔰 Refer to the [Subscription API documentation](https://pkg.go.dev/github.com/operator-framework/api@v0.14.0/pkg/operators/v1alpha1#Subscription).
 
 Here are some examples of configuration that can be achieved by modifying the Subscription resource.
-In each case we assume that you are starting with the following [default Subscription from OperatorHub.io]((https://operatorhub.io/install/cert-manager.yaml)):
+In each case we assume that you are starting with the following [default Subscription from OperatorHub.io](https://operatorhub.io/install/cert-manager.yaml):
 
 ```yaml
 # cert-manager.yaml

content/docs/installation/upgrading/upgrading-0.16-1.0.md

@@ -7,7 +7,7 @@ description: 'cert-manager installation: Upgrading v0.16 to v1.0'
 
 ## Issue with older versions of `kubectl`
 `kubectl` versions with patch versions lower than `v1.18.8` `v1.17.11` or `v1.16.14` have issues updating from the `v0.16` CRD files, due to [a bug when handling deeply nested CRDs](https://github.com/kubernetes/kubernetes/issues/91615).
-This bug will make `kubectl apply -f [...]` hang. 
+This bug will make `kubectl apply -f [...]` hang.
 
 This bug only happens during a re-apply of the v0.16 CRDs or upgrading from it. Upgrades from lower versions do not cause issues. If you have this issue please upgrade your `kubectl` to the latest patch release.
 Versions of `kubectl` of `v1.15.x` or below are not being supported anymore as these are unsupported by the Kubernetes community.
@@ -42,8 +42,8 @@ you have to transition all resources to `cert-manager.io/v1`.
 
 This makes for a fairly significant breaking change for users, as **all**
 cert-manager resources will need to be updated to reflect these changes.
-Ingress annotations will stay the same, this means if you only use ingress-shim 
-you do not have to convert these resources over but it is recommended. 
+Ingress annotations will stay the same, this means if you only use ingress-shim
+you do not have to convert these resources over but it is recommended.
 However you should convert the (Cluster)Issuers and delete the old CRD versions.
 
 This upgrade MUST be performed in the following sequence of steps:
@@ -78,17 +78,17 @@ kubectl get -o yaml \
 
 #### Converting resources
 
-You can use our [kubectl plugin](../../usage/kubectl-plugin.md) to automatically convert your backup from `v1alpha2` to `v1` using the following command:
+You can use [cmctl convert](../../reference/cmctl.md#convert) to automatically convert your backup from `v1alpha2` to `v1` using the following command:
 
 ```bash
-kubectl cert-manager convert --output-version cert-manager.io/v1 -f cert-manager-backup.yaml > cert-manager-v1.yaml
+cmctl convert --output-version cert-manager.io/v1 -f cert-manager-backup.yaml > cert-manager-v1.yaml
 ```
 
-*Tip:* you can use `kubectl apply --dry-run` on a local/test cluster with cert-manager `v1.0` installed to validate your conversion 
+*Tip:* you can use `kubectl apply --dry-run` on a local/test cluster with cert-manager `v1.0` installed to validate your conversion
 
 
 #### Uninstall cert-manager
-Next step is to uninstall cert-manager. 
+Next step is to uninstall cert-manager.
 This will cause a temporary halt to renewal of certificates but will not affect any TLS traffic.
 
 How you do this depends on how you installed cert-manager.
@@ -109,7 +109,7 @@ You can do this manually by executing the following commands:
 kubectl delete crd certificaterequests.cert-manager.io
 kubectl delete crd certificates.cert-manager.io
 kubectl delete crd challenges.acme.cert-manager.io
-kubectl delete crd clusterissuers.cert-manager.io 
+kubectl delete crd clusterissuers.cert-manager.io
 kubectl delete crd issuers.cert-manager.io
 kubectl delete crd orders.acme.cert-manager.io
 ```
@@ -124,4 +124,4 @@ Once it has been fully installed you can re-apply the converted resources:
 kubectl apply -f cert-manager-v1.yaml
 ```
 
-Congratulations you're now fully upgraded to cert-manager `v1.0`
+Congratulations you're now fully upgraded to cert-manager `v1.0`

content/docs/projects/approver-policy.md

@@ -4,19 +4,19 @@ description: ''
 ---
 
 approver-policy is a cert-manager
-[approver](https://cert-manager.io/docs/concepts/certificaterequest/#approval)
+[approver](../concepts/certificaterequest.md#approval)
 that will approve or deny CertificateRequests based on CRD defined policies.
 
 ---
 
 ## Installation
 
-[cert-manager](https://cert-manager.io) is required to be installed with approver-policy.
+[cert-manager](../installation/README.md) is required to be installed with approver-policy.
 
 > ⚠️
 >
 > It is important that the
-> [default approver is disabled in cert-manager](https://cert-manager.io/docs/concepts/certificaterequest/#approver-controller).
+> [default approver is disabled in cert-manager](../concepts/certificaterequest.md#approver-controller).
 > If the default approver is not disabled in cert-manager, approver-policy will
 > race with cert-manager and thus policy becomes useless.
 >
@@ -34,10 +34,10 @@ $ helm upgrade -i -n cert-manager cert-manager-approver-policy jetstack/cert-man
 ```
 
 If you are using approver-policy with [external
-issuers](https://cert-manager.io/docs/configuration/external/), you _must_
+issuers](../configuration/external.md), you _must_
 include their signer names so that approver-policy has permissions to approve
 and deny CertificateRequests that
-[reference them](https://cert-manager.io/docs/concepts/certificaterequest/#rbac-syntax).
+[reference them](../concepts/certificaterequest.md#rbac-syntax).
 For example, if using approver-policy for the internal issuer types, along with
 [google-ca-issuer](https://github.com/jetstack/google-cas-issuer), and
 [aws-privateca-issuer](https://github.com/cert-manager/aws-privateca-issuer),
@@ -269,7 +269,7 @@ CertificateRequestPolicies against CertificateRequests for evaluation.  A
 CertificateRequestPolicy must select, and therefore match, a CertificateRequest
 for it to be considered for evaluation of the request.
 
-> ⚠️ Note that the user must still be bound by [RBAC](#Configuration) for
+> ⚠️ Note that the user must still be bound by [RBAC](#configuration) for
 > the policy to be considered for evaluation against a request.
 
 approver-policy supports selecting over the `issuerRef` and the `namespace` of a

content/docs/projects/csi-driver.md

@@ -34,7 +34,7 @@ no extra configuration however `v1.15` requires the following feature gate set:
 
 You must have a working installation of cert-manager present on the cluster.
 Instructions on how to install cert-manager can be found
-[on cert-manager.io](https://cert-manager.io/docs/installation/).
+[on cert-manager.io](../installation/README.md).
 
 To install the csi-driver, use helm install:
 
@@ -122,7 +122,7 @@ this process has been completed.
 
 For more information on how to set up issuers for your cluster, refer to the
 cert-manager documentation
-[here](https://cert-manager.io/docs/configuration/). **Note** it is not
+[here](../configuration/README.md). **Note** it is not
 possible to use `SelfSigned` Issuers with the CSI Driver. In order for
 cert-manager to self sign a certificate, it needs access to the secret
 containing the private key that signed the certificate request to sign the end
@@ -194,9 +194,9 @@ volumeAttributes:
 ## Requesting Certificates using the mounting Pod's ServiceAccount
 
 If the flag `--use-token-request` is enabled on the csi-driver DaemonSet, the
-[CertificateRequest](../concepts/certificaterequest/) resource will be created
+[CertificateRequest](../concepts/certificaterequest.md) resource will be created
 by the mounting Pod's ServiceAccount. This can be pared with
-[approver-policy](./approver-policy/) to enable advanced policy on a per
+[approver-policy](./approver-policy.md) to enable advanced policy on a per
 ServiceAccount basis.
 
 Ensure to give permissions to Pod ServiceAccounts to create CertificateRequests

content/docs/reference/cmctl.md

@@ -226,7 +226,7 @@ of these commands are subject to change or removal in future releases.
 Sub-commands are available to create different resources:
 
 ##### CertificateSigningRequest
-To create a [CertificateSigningRequest](./kube-csr.md), use
+To create a [CertificateSigningRequest](../usage/kube-csr.md), use
 ```console
 cmctl x create csr
 ```

content/docs/release-notes/release-notes-0.16.md

@@ -20,7 +20,7 @@ private key management and renewal.
 
 In `v0.15` we added the new certificate controllers under a feature gate to allow users to test these and gather feedback.
 Thanks to everyone testing these and reporting issues we were able to fix issues and improve the controller.
-In `v0.16` this controller is now the default one in cert-manager. 
+In `v0.16` this controller is now the default one in cert-manager.
 
 For more information on this, we invite you to read our [design document](https://github.com/cert-manager/cert-manager/pull/2753).
 
@@ -31,16 +31,16 @@ cert-manager `v0.15` included a kubectl plugin that allows users to interact wit
 In this release we have added a new sub-command to the cert-manager CLI which allows users to sign certificates on their computer
 or inside a container.
 
-The `kubectl cert-manager create certificaterequest` command creates a new CertificateRequest 
+The `kubectl cert-manager create certificaterequest` command creates a new CertificateRequest
 resource based on the YAML manifest of a Certificate resource as specified by `--from-certificate-file` flag.
- 
+
 For example this will create a CertificateRequest resource with the name "my-cr" based on the Certificate described in `my-certificate.yaml` while storing the
 private key and X.509 certificate in `my-cr.key` and `my-cr.crt` respectively.
 ```console
 $ kubectl cert-manager create certificaterequest my-cr --from-certificate-file my-certificate.yaml --fetch-certificate --timeout 20m
 ```
 
-More information can be found on our [kubectl plugin page](../usage/kubectl-plugin.md).
+More information can be found on our [kubectl plugin page](../reference/cmctl.md#legacy-kubectl-plugin).
 
 ## `v1beta1` API
 
@@ -77,7 +77,7 @@ ACME Challenge:
 
 If you're using Kubernetes 1.15 or higher, conversion webhooks will allow you seamlessly interact with `v1alpha2`, `v1alpha3` and `v1beta1`
 API versions at the same time. This allows you to use the new API version without having to modify or redeploy your older resources.
-Users of the `legacy` version of cert-manager will still only have the `v1alpha2` API. 
+Users of the `legacy` version of cert-manager will still only have the `v1alpha2` API.
 
 ### `kubectl cert-manager convert` tool
 
@@ -88,4 +88,4 @@ The `kubectl cert-manager convert` command will be able to convert your manifest
 $ kubectl cert-manager convert --output-version cert-manager.io/v1beta1 cert.yaml
 ```
 
-More information can be found on our [kubectl plugin page](../usage/kubectl-plugin.md).
+More information can be found on our [kubectl plugin page](../reference/cmctl.md#legacy-kubectl-plugin).

content/docs/release-notes/release-notes-1.0.md

@@ -145,12 +145,12 @@ For users of Kubernetes `v1.15` we keep offering support for the `v1beta1` Kuber
 For this release we upgraded our logging library to `klog/v2` analog to Kubernetes `v1.19`.
 We also reviewed every log we write to assign it an appropriate log level.
 
-We followed the (Kubernetes logging guidelines)[https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md]. To come up with 5 log levels ranging from `Error` (level 0) which only prints important errors to `Trace` (level 5) which can help you to know exactly what is gong on.
+We followed the [Kubernetes logging guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md). To come up with 5 log levels ranging from `Error` (level 0) which only prints important errors to `Trace` (level 5) which can help you to know exactly what is gong on.
 With this change we reduced the number of logs when you don't need to have a debugging trace while running cert-manager.
 
 Tip: My default cert-manager runs on level 2 (Info), you can set this using `global.logLevel` in the Helm chart.
 
-*Note*: Looking at the logs while troubleshooting cert-manager should be last resort behavior, for more info check out our [troubleshooting guide](../faq/troubleshooting.md)
+*Note*: Looking at the logs while troubleshooting cert-manager should be last resort behavior, for more info check out our [troubleshooting guide](../troubleshooting/README.md)
 
 ## ACME improvements
 
@@ -213,4 +213,4 @@ spec:
     preferredChain: "DST Root CA X3"
 ```
 
-Note that this Root CA is expiring soon, Let's Encrypt will keep this certificate chain active until September 29 2021.
+Note that this Root CA is expiring soon, Let's Encrypt will keep this certificate chain active until September 29 2021.

content/docs/release-notes/release-notes-1.11.md

@@ -18,7 +18,7 @@ Instead cert-manager authenticates to Azure using a short lived Kubernetes Servi
 This is now the recommended authentication method because it is more secure and easier to maintain than the other methods,
 and it should be used instead of the [deprecated pod-managed identify mechanism](https://github.com/Azure/aad-pod-identity#-announcement).
 
-> 📖 Read about [configuring the ACME issuer with Azure DNS](../configuration/acme/dns01/azuredns/README.md).
+> 📖 Read about [configuring the ACME issuer with Azure DNS](../configuration/acme/dns01/azuredns.md).
 >
 > 📖 Read the [AKS + LoadBalancer + Let's Encrypt tutorial](../tutorials/getting-started-aks-letsencrypt/README.md) for an end-to-end example of this authentication method.
 >
@@ -31,7 +31,7 @@ complies with the ACME spec for the ACME issuer, but some users had issues when
 either that they ignore certificate validation (which is insecure) or that they hack their certificate into the cert-manager trust store.
 
 Now, users can set a caBundle flag on their ACME issuer, specifying the trust store that cert-manager should use when communicating with the
-server. For more details, see [Private ACME Servers](../configuration/acme.md#private-acme-servers)
+server. For more details, see [Private ACME Servers](../configuration/acme/README.md#private-acme-servers)
 
 ### `LiteralSubject` Improvements
 

content/docs/troubleshooting/acme.md

@@ -14,7 +14,7 @@ investigate and debug if there is a problem during the process. You can read
 more about these resources in the [concepts
 pages](../concepts/acme-orders-challenges.md).
 
-Before you start here you should probably take a look at our [general troubleshooting guide](./troubleshooting.md)
+Before you start here you should probably take a look at our [general troubleshooting guide](./README.md)
 
 ## 1. Troubleshooting (Cluster)Issuers
 

content/docs/tutorials/acme/nginx-ingress.md

@@ -227,7 +227,7 @@ Your other option is to replace your `Issuers` with `ClusterIssuers`;
 If using a `ClusterIssuer`, remember to update the Ingress annotation `cert-manager.io/issuer` to
 `cert-manager.io/cluster-issuer`.
 
-If you see issues with issuers, follow the [Troubleshooting Issuing ACME Certificates](../../faq/acme.md) guide.
+If you see issues with issuers, follow the [Troubleshooting Issuing ACME Certificates](../../troubleshooting/acme.md) guide.
 
 More information on the differences between `Issuers` and `ClusterIssuers` - including
 when you might choose to use each can be found on [Issuer concepts](../../concepts/issuer.md#namespaces).

content/docs/tutorials/getting-started-aks-letsencrypt/README.md

@@ -344,7 +344,7 @@ The advantages of this method are that cert-manager will use an ephemeral Kubern
 > ℹ️ cert-manager `>= v1.11.0` supports workload identity federation for ACME (Let's Encrypt) DNS-01 with Azure DNS.
 > Older versions of cert-manager support other authentication mechanisms which are not covered in this tutorial.
 >
-> 📖 Read about [other ways to configure the ACME issuer with Azure DNS](../../configuration/acme/dns01/azuredns/README.md).
+> 📖 Read about [other ways to configure the ACME issuer with Azure DNS](../../configuration/acme/dns01/azuredns.md).
 
 ## Install the Azure workload identity features
 
@@ -684,4 +684,4 @@ az identity delete --name $USER_ASSIGNED_IDENTITY_NAME
 
 > 📖 Read other [cert-manager tutorials](../README.md) and [getting started guides](../../getting-started/README.md).
 >
-> 📖 Read more about [configuring the cert-manager ACME issuer with Azure DNS](../../configuration/acme/dns01/azuredns/README.md).
+> 📖 Read more about [configuring the cert-manager ACME issuer with Azure DNS](../../configuration/acme/dns01/azuredns.md).