From 7d7c4fdaefa1d8fa94a8d0dd41f208e3542d44ca Mon Sep 17 00:00:00 2001 From: Richard Wall Date: Thu, 19 Jan 2023 12:30:18 +0000 Subject: [PATCH 1/4] Run link check via a GitHub Actions job Signed-off-by: Richard Wall --- .github/workflows/check.yaml | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/.github/workflows/check.yaml b/.github/workflows/check.yaml index 7e4f0b473d..ea53f96081 100644 --- a/.github/workflows/check.yaml +++ b/.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 From 8357ebc85a2f5a0a89adc3bd58bf2a4dff521937 Mon Sep 17 00:00:00 2001 From: Richard Wall Date: Thu, 19 Jan 2023 12:30:48 +0000 Subject: [PATCH 2/4] Document the automated checks Signed-off-by: Richard Wall --- README.md | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index b5be79b5cf..e96daa7da9 100644 --- a/README.md +++ b/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. From b18307bf67ab603e299e595bf866a9bf88c82109 Mon Sep 17 00:00:00 2001 From: Richard Wall Date: Thu, 19 Jan 2023 14:00:47 +0000 Subject: [PATCH 3/4] Fix broken links Signed-off-by: Richard Wall --- content/docs/concepts/issuer.md | 2 +- content/docs/concepts/webhook.md | 2 +- .../2022/improve-navigation-and-structure.md | 2 +- .../installation/operator-lifecycle-manager.md | 2 +- .../upgrading/upgrading-0.16-1.0.md | 18 +++++++++--------- content/docs/projects/approver-policy.md | 12 ++++++------ content/docs/projects/csi-driver.md | 8 ++++---- content/docs/reference/cmctl.md | 2 +- .../docs/release-notes/release-notes-0.16.md | 12 ++++++------ .../docs/release-notes/release-notes-1.0.md | 6 +++--- .../docs/release-notes/release-notes-1.11.md | 4 ++-- content/docs/troubleshooting/acme.md | 2 +- content/docs/tutorials/acme/nginx-ingress.md | 2 +- .../getting-started-aks-letsencrypt/README.md | 4 ++-- .../README.md | 6 +++--- content/docs/tutorials/istio-csr/istio-csr.md | 2 +- content/docs/usage/approver-policy.md | 6 +++--- content/docs/usage/certificate.md | 6 +++--- content/docs/usage/csi.md | 2 +- content/docs/usage/istio.md | 2 +- content/docs/usage/kube-csr.md | 4 ++-- 21 files changed, 53 insertions(+), 53 deletions(-) diff --git a/content/docs/concepts/issuer.md b/content/docs/concepts/issuer.md index f9b4a7bf59..6293369992 100644 --- a/content/docs/concepts/issuer.md +++ b/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). \ No newline at end of file +cert-manager [configuration documentation](../configuration/README.md). diff --git a/content/docs/concepts/webhook.md b/content/docs/concepts/webhook.md index cef153eb9c..1bcbbee769 100644 --- a/content/docs/concepts/webhook.md +++ b/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). diff --git a/content/docs/contributing/google-season-of-docs/2022/improve-navigation-and-structure.md b/content/docs/contributing/google-season-of-docs/2022/improve-navigation-and-structure.md index 908a58206a..8f23636af3 100644 --- a/content/docs/contributing/google-season-of-docs/2022/improve-navigation-and-structure.md +++ b/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 diff --git a/content/docs/installation/operator-lifecycle-manager.md b/content/docs/installation/operator-lifecycle-manager.md index 3ce308acc6..f9982899ad 100644 --- a/content/docs/installation/operator-lifecycle-manager.md +++ b/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 diff --git a/content/docs/installation/upgrading/upgrading-0.16-1.0.md b/content/docs/installation/upgrading/upgrading-0.16-1.0.md index c9144a5b24..2358ec40a3 100644 --- a/content/docs/installation/upgrading/upgrading-0.16-1.0.md +++ b/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` \ No newline at end of file +Congratulations you're now fully upgraded to cert-manager `v1.0` diff --git a/content/docs/projects/approver-policy.md b/content/docs/projects/approver-policy.md index 22cfdc492d..4b991df08f 100644 --- a/content/docs/projects/approver-policy.md +++ b/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 diff --git a/content/docs/projects/csi-driver.md b/content/docs/projects/csi-driver.md index a816afb2d1..ab9cc84f60 100644 --- a/content/docs/projects/csi-driver.md +++ b/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 diff --git a/content/docs/reference/cmctl.md b/content/docs/reference/cmctl.md index 6e25d70fb1..095c9dfe6e 100644 --- a/content/docs/reference/cmctl.md +++ b/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 ``` diff --git a/content/docs/release-notes/release-notes-0.16.md b/content/docs/release-notes/release-notes-0.16.md index 63bb45f878..40b98c2292 100644 --- a/content/docs/release-notes/release-notes-0.16.md +++ b/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). \ No newline at end of file +More information can be found on our [kubectl plugin page](../reference/cmctl.md#legacy-kubectl-plugin). diff --git a/content/docs/release-notes/release-notes-1.0.md b/content/docs/release-notes/release-notes-1.0.md index 27de4f29e5..94e67568f2 100644 --- a/content/docs/release-notes/release-notes-1.0.md +++ b/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. \ No newline at end of file +Note that this Root CA is expiring soon, Let's Encrypt will keep this certificate chain active until September 29 2021. diff --git a/content/docs/release-notes/release-notes-1.11.md b/content/docs/release-notes/release-notes-1.11.md index 171d270c9a..65a014fa55 100644 --- a/content/docs/release-notes/release-notes-1.11.md +++ b/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 diff --git a/content/docs/troubleshooting/acme.md b/content/docs/troubleshooting/acme.md index 11188db640..c8b527b1cf 100644 --- a/content/docs/troubleshooting/acme.md +++ b/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 diff --git a/content/docs/tutorials/acme/nginx-ingress.md b/content/docs/tutorials/acme/nginx-ingress.md index b51bbef46b..6b98f348e3 100644 --- a/content/docs/tutorials/acme/nginx-ingress.md +++ b/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). diff --git a/content/docs/tutorials/getting-started-aks-letsencrypt/README.md b/content/docs/tutorials/getting-started-aks-letsencrypt/README.md index 38a8ce5888..d67eeabfa4 100644 --- a/content/docs/tutorials/getting-started-aks-letsencrypt/README.md +++ b/content/docs/tutorials/getting-started-aks-letsencrypt/README.md @@ -423,7 +423,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 @@ -809,4 +809,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). diff --git a/content/docs/tutorials/getting-started-with-cert-manager-on-google-kubernetes-engine-using-lets-encrypt-for-ingress-ssl/README.md b/content/docs/tutorials/getting-started-with-cert-manager-on-google-kubernetes-engine-using-lets-encrypt-for-ingress-ssl/README.md index e6c8538d75..80f233aee7 100644 --- a/content/docs/tutorials/getting-started-with-cert-manager-on-google-kubernetes-engine-using-lets-encrypt-for-ingress-ssl/README.md +++ b/content/docs/tutorials/getting-started-with-cert-manager-on-google-kubernetes-engine-using-lets-encrypt-for-ingress-ssl/README.md @@ -474,7 +474,7 @@ Example output: > ℹī¸ Adding the annotation `cert-manager.io/issuer: letsencrypt-staging` marks the Ingress for the attention of the cert-manager `ingress-shim` > and causes it to create a new Certificate with a reference to the Issuer that we created earlier. > -> 🔰 Read [Securing Ingress Resources](../../usage/ingress) to learn more. +> 🔰 Read [Securing Ingress Resources](../../usage/ingress.md) to learn more. > > 🔰 Read about how to [Specify certificates for your Ingress in GKE](https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-multi-ssl#specifying_certificates_for_your_ingress). @@ -624,11 +624,11 @@ Events: ### Use cmctl to show the state of a Certificate and its associated resources -> ℹī¸ [Install `cmctl`](../../reference/cmctl) if you have not already done so. +> ℹī¸ [Install `cmctl`](../../reference/cmctl.md) if you have not already done so. When you create a Certificate, cert-manager will create a collection of temporary resources which each contain information about the status of certificate signing process. -You can read more about these in the [Certificate Lifecycle](../../concepts/certificate#certificate-lifecycle) section. +You can read more about these in the [Certificate Lifecycle](../../concepts/certificate.md#certificate-lifecycle) section. Use the `cmctl status` command to view details of all these resources and all the associated Events and error messages. You may see some temporary errors, like: diff --git a/content/docs/tutorials/istio-csr/istio-csr.md b/content/docs/tutorials/istio-csr/istio-csr.md index fc58cdc057..32c5c1ae3e 100644 --- a/content/docs/tutorials/istio-csr/istio-csr.md +++ b/content/docs/tutorials/istio-csr/istio-csr.md @@ -78,7 +78,7 @@ kubectl create secret generic -n cert-manager istio-root-ca --from-file=ca.pem=c ## Installing istio-csr istio-csr is best installed via Helm, and it should be simple and quick to install. There -are a bunch of other configuration options for the helm chart, which you can check out [here](../usage/istio-csr/istio-csr.md). +are a bunch of other configuration options for the helm chart, which you can check out [here](../../projects/istio-csr.md). ```console helm repo add jetstack https://charts.jetstack.io diff --git a/content/docs/usage/approver-policy.md b/content/docs/usage/approver-policy.md index 730802d7bc..09d5768f3d 100644 --- a/content/docs/usage/approver-policy.md +++ b/content/docs/usage/approver-policy.md @@ -3,12 +3,12 @@ title: Policy for cert-manager certificates description: 'cert-manager usage: approver-policy' --- -cert-manager [CertificateRequests](../concepts/certificaterequest/) can be +cert-manager [CertificateRequests](../concepts/certificaterequest.md) can be rejected from being signed by using the [approval -API](../concepts/certificaterequest/#approval). +API](../concepts/certificaterequest.md#approval). [approver-policy](https://github.com/cert-manager/approver-policy) is a cert-manager project that enables you to write policy to automatically manage this approval mechanism. -Please read the [project page](../projects/approver-policy/) for more +Please read the [project page](../projects/approver-policy.md) for more information on how to install and use approver-policy. diff --git a/content/docs/usage/certificate.md b/content/docs/usage/certificate.md index 32a3d2c20b..d0bce92755 100644 --- a/content/docs/usage/certificate.md +++ b/content/docs/usage/certificate.md @@ -216,7 +216,7 @@ certificate object is reissued under the following circumstances: ```sh cmctl renew cert-1 ``` - Note that the above command requires [cmctl](./cmctl.md#renew). + Note that the above command requires [cmctl](../reference/cmctl.md#renew).
@@ -224,7 +224,7 @@ certificate object is reissued under the following circumstances: **not a recommended solution** for manually rotating the private key. The recommended way to manually rotate the private key is to trigger the reissuance of the Certificate resource with the following command (requires -[`cmctl`](./cmctl.md#renew)): +[`cmctl`](../reference/cmctl.md#renew)): ```sh cmctl renew cert-1 @@ -365,4 +365,4 @@ type: kubernetes.io/tls data: key.der: ... -``` \ No newline at end of file +``` diff --git a/content/docs/usage/csi.md b/content/docs/usage/csi.md index e6607ccf0b..5e1a6124b0 100644 --- a/content/docs/usage/csi.md +++ b/content/docs/usage/csi.md @@ -6,7 +6,7 @@ description: 'cert-manager usage: CSI driver' ## Enabling mTLS of Pods using the cert-manager CSI Driver A [Container Storage Interface (CSI) -driver](../projects/csi-driver) has been created to +driver](../projects/csi-driver.md) has been created to facilitate mTLS of Pods running inside your cluster through use of cert-manager. Using this driver will ensure that the private key and corresponding signed certificate will be unique to each Pod and will be stored on disk to the node diff --git a/content/docs/usage/istio.md b/content/docs/usage/istio.md index 71ced67f88..86149ae22b 100644 --- a/content/docs/usage/istio.md +++ b/content/docs/usage/istio.md @@ -14,4 +14,4 @@ plane and workload certificates via your chosen cert-manager Issuer. --- Please follow the instructions for installing and using istio-csr on the -[project page](../projects/istio-csr). +[project page](../projects/istio-csr.md). diff --git a/content/docs/usage/kube-csr.md b/content/docs/usage/kube-csr.md index dab4da9f89..f6abb93f74 100644 --- a/content/docs/usage/kube-csr.md +++ b/content/docs/usage/kube-csr.md @@ -155,7 +155,7 @@ Signer annotations: ## Usage CertificateSigningRequests can be manually created using -[cmctl](./cmctl.md#experimental). +[cmctl](../reference/cmctl.md#experimental). This command takes a manifest file containing a [Certificate](../usage/certificate.md) resource as input. This generates a private key and creates a CertificateSigningRequest. CertificateSigningRequests @@ -163,4 +163,4 @@ are not approved by default, so you will likely need to approve it manually: ```bash $ kubectl certificate approve -``` \ No newline at end of file +``` From e521164af8fb5ec269e58fdb9313b1bc0a8d0c8a Mon Sep 17 00:00:00 2001 From: Richard Wall Date: Thu, 19 Jan 2023 14:28:32 +0000 Subject: [PATCH 4/4] Ignore external, public and anchor links Checking external links is flaky due to network and rate limiting Checking anchor links doesn't work when the anchors have been specified using ` --- markdown-link-check.json | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/markdown-link-check.json b/markdown-link-check.json index ef469a3d4a..c8d6a8984b 100644 --- a/markdown-link-check.json +++ b/markdown-link-check.json @@ -1,13 +1,21 @@ { "ignorePatterns": [ { - "pattern": "^https://github.com" + "description": "Ignore root relative links to images which markdown-link-check is unable to verify", + "pattern": "^/" }, { - "pattern": "^https://acme.example.com" + "description": "Ignore in-page anchor links defined using syntax,. See https://github.com/tcort/markdown-link-check/issues/225", + "pattern": "^#" }, { - "pattern": "^https://developers.cloudflare.com" + "description": "Ignore external links which may fail due to network flakiness and rate limits on foreign servers", + "pattern": "^https?://" + }, + { + "description": "Ignore links to yaml manifests which are served from public/, which markdown-link-check is unable to verify", + "pattern": "^[^:/]+.yaml" } - ] + ], + "aliveStatusCodes": [200, 0] }