Merge pull request #1287 from cert-manager/standardise_page_references

Use same method for creating on-page references links across all pages

content/docs/configuration/acme/README.md

@@ -367,11 +367,9 @@ spec:
 ```
 
 
-## Alternative Certificate Chains
-
 {/* The empty link below preserves old links to #alternative-certificate-chain", which matched the old title of this section */}
-
-<a id="alternative-certificate-chain" className="hidden-link"></a>
+<a id="alternative-certificate-chain"></a>
+## Alternative Certificate Chains
 
 It's possible to choose alternative certificate chains when fetching a certificate from an ACME server. This allows issuers to gracefully roll people over to a new root certificate during a transition period; the most famous example was the Let's Encrypt ["ISRG Root" changeover](https://community.letsencrypt.org/t/transition-to-isrgs-root-delayed-until-jan-11-2021/125516).
 

content/docs/configuration/acme/http01/README.md

@@ -101,7 +101,8 @@ solver, potentially incurring additional cost.
 
 </div>
 
-<h3 id="ingress-service-type">`serviceType`</h3>
+<a id="ingress-service-type"></a>
+### `serviceType`
 
 In rare cases it might be not possible/desired to use `NodePort` as type for the
 HTTP01 challenge response service, e.g. because of Kubernetes limit
@@ -348,7 +349,8 @@ spec:
 
 After the Certificate is issued, the HTTPRoute is deleted.
 
-<h3 id="gatewayhttproute-labels">`labels`</h3>
+<a id="gatewayhttproute-labels"></a>
+### `labels`
 
 These labels are copied into the temporary HTTPRoute created by cert-manager for
 solving the HTTP-01 challenge. These labels must match one of the Gateway
@@ -357,7 +359,8 @@ resources on your cluster. The matched Gateway have a listener on port 80.
 Note that when the labels do not match any Gateway on your cluster, cert-manager
 will create the temporary HTTPRoute challenge and nothing will happen.
 
-<h3 id="gatewayhttproute-service-type">`serviceType`</h3>
+<a id="gatewayhttproute-service-type"></a>
+### `serviceType`
 
 This field has the same meaning as the
 [`http01.ingress.serviceType`](#ingress-service-type).

content/docs/faq/README.md

@@ -91,11 +91,9 @@ cert-manager publishes all events to the Kubernetes events mechanism, you can ge
 
 Due to the nature of the Kubernetes event mechanism these will be purged after a while. If you're using a dedicated logging system it might be able or is already also storing Kubernetes events.
 
-### What happens if issuance fails? Will it be retried?
-
 {/* This empty link preserves old links to #what-happens-if-a-renewal-doesn't happen?-will-it-be-tried-again-after-some-time?", which matched the old title of this section */}
-
-<a id="alternative-certificate-chain" className="hidden-link"></a>
+<a id="alternative-certificate-chain"></a>
+### What happens if issuance fails? Will it be retried?
 
 cert-manager will retry a failed issuance except for a few rare edge cases where
 manual intervention is needed.

content/docs/installation/supported-releases.md

@@ -13,7 +13,8 @@ Each release is supported for a period of four months, and we aim to create a ne
 release roughly every two months, accounting for holiday periods, major conferences
 and other world events.
 
-<h2 id="supported-releases">Currently supported releases</h2>
+<a id="supported-releases"></a>
+## Currently supported releases
 
 | Release | Release Date | End of Life | [Supported Kubernetes versions][s] | [Supported OpenShift versions][s] |
 |----------|:------------:|:----------------------:|:----------------------------------:|:---------------------------------:|
@@ -117,7 +118,8 @@ branch is actually supported.
  April 1, 2021
 ```
 
-<h3 id="technical-support">Technical support</h3>
+<a id="technical-support"></a>
+### Technical support
 
 Technical assistance is offered on a best-effort basis for supported
 releases only. You can request support from the community on [Kubernetes
@@ -128,7 +130,8 @@ Google group.
 [discussions]: https://github.com/cert-manager/cert-manager/discussions
 [group]: https://groups.google.com/g/cert-manager-dev
 
-<h3 id="bug-fixes-support">Security and bug fixes</h3>
+<a id="bug-fixes-support"></a>
+### Security and bug fixes
 
 We back-port important bug fixes — including security fixes — to all
 currently supported releases.
@@ -137,12 +140,14 @@ currently supported releases.
 - [Critical bugs](#critical-bugs),
 - [Long-standing bugs](#long-standing-bugs).
 
-<h4 id="security-issues">Security issues</h4>
+<a id="security-issues"></a>
+#### Security issues
 
 **Security issues** are fixed as soon as possible. They get back-ported to
 the last two releases, and a new patch release is immediately created for them.
 
-<h4 id="critical-bugs">Critical bugs</h4>
+<a id="critical-bugs"></a>
+#### Critical bugs
 
 **Critical bugs** include both regression bugs as well as upgrade bugs.
 
@@ -159,7 +164,8 @@ this category.
 Fixes for critical bugs are (usually) immediately back-ported by creating a new
 patch release for the currently supported releases.
 
-<h4 id="long-standing-bugs">Long-standing bugs</h4>
+<a id="long-standing-bugs"></a>
+#### Long-standing bugs
 
 **Long-standing bug**: sometimes a bug exists for a long time, and may have
 known workarounds. [#3444][] is an example of a long-standing bug.
@@ -168,14 +174,16 @@ Where we feel that back-porting would be difficult or might be a stability
 risk to clusters running cert-manager, we'll make the fix in a major
 release but avoid back-porting the fix.
 
-<h4 id="breaking-changes">Breaking changes</h4>
+<a id="breaking-changes"></a>
+#### Breaking changes
 
 Breaking changes are changes that intentionally break the cert-manager
 Kubernetes API or the command line flags. We avoid making breaking changes
 where possible, and where they're required we'll give as much notice as
 possible.
 
-<h4 id="other-backports">Other back-ports</h4>
+<a id="other-backports"></a>
+#### Other back-ports
 
 We aim to be conservative in what we back-port. That applies especially for anything which
 could be a _runtime_ change - that is, a change which might alter behavior for someone
@@ -201,7 +209,8 @@ Generally we'll seek to be pragmatic. A rule of thumb might be to ask:
 [#5209]: https://github.com/cert-manager/cert-manager/pull/5209 "release-1.8: rclone"
 
 
-<h2 id="kubernetes-supported-versions">How we determine supported Kubernetes versions</h2>
+<a id="kubernetes-supported-versions"></a>
+## How we determine supported Kubernetes versions
 
 The list of supported Kubernetes versions displayed in the [Supported Releases](#supported-releases) section
 depends on what the cert-manager maintainers think is reasonable to support and to test.

content/docs/troubleshooting/webhook.md

@@ -216,7 +216,6 @@ the webhook deployment, the argument `--healthz-port=6081` was mismatched with
 the readiness configuration.
 
 <a id="io-timeout"></a>
-
 ## Error: `i/o timeout` (connectivity issue)
 
 > This error message was reported 26 times on Slack. To list these messages, do a search with `in:#cert-manager in:#cert-manager-dev "443: i/o timeout"`. The error message was reported in 2 GitHub issues ([#2811](https://github.com/cert-manager/cert-manager/issues/2811 "i/o timeout from apiserver when connecting to webhook on k3s"), [#4073](https://github.com/cert-manager/cert-manager/issues/4073 "Internal error occurred: failed calling webhook"))
@@ -242,7 +241,6 @@ inside the webhook's net namespace, we would see:
 This issue is caused by the `SYN` packet being dropped somewhere.
 
 <a id="gke-private-cluster"></a>
-
 ### Cause 1: GKE Private Cluster
 
 The default Helm configuration should work with GKE private clusters, but
@@ -552,7 +550,6 @@ Error from server (InternalError): error when creating "STDIN":
 ([1](https://kubernetes.slack.com/archives/C4NV3DWUC/p1632849763397100)).
 
 <a id="context-deadline-exceeded"></a>
-
 ## Error: `context deadline exceeded`
 
 > This error message was reported in GitHub issues ([2319](https://github.com/cert-manager/cert-manager/issues/2319 "Documenting context deadline exceeded errors relating to the webhook, on bare metal"), [2706](https://github.com/cert-manager/cert-manager/issues/2706 "") [5189](https://github.com/cert-manager/cert-manager/issues/5189 "Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s: context deadline exceeded"), [5004](https://github.com/cert-manager/cert-manager/issues/5004 "After installing cert-manager using kubectl, cmctl check api fails with https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s: context deadline exceeded")), and once [on Stack Overflow](https://stackoverflow.com/questions/72059332/how-can-i-fix-failed-calling-webhook-webhook-cert-manager-io).

content/docs/usage/certificate.md

@@ -117,7 +117,8 @@ The `Certificate` will be issued using the issuer named `ca-issuer` in the
 A full list of the fields supported on the Certificate resource can be found in
 the [API reference documentation](../reference/api-docs.md#cert-manager.io/v1.CertificateSpec).
 
-<h2 id="key-usages">X.509 key usages and extended key usages</h2>
+<a id="key-usages"></a>
+## X.509 key usages and extended key usages
 
 cert-manager supports requesting certificates that have a number of [custom key
 usages](https://tools.ietf.org/html/rfc5280#section-4.2.1.3) and [extended key
@@ -134,7 +135,8 @@ certificate does not match the current key usage set.
 An exhaustive list of supported key usages can be found in the [API reference
 documentation](../reference/api-docs.md#cert-manager.io/v1.KeyUsage).
 
-<h2 id="temporary-certificates-whilst-issuing">Temporary Certificates while Issuing</h2>
+<a id="temporary-certificates-whilst-issuing"></a>
+## Temporary Certificates while Issuing
 
 When requesting certificates [using the ingress-shim](./ingress.md), the
 component `ingress-gce`, if used, requires that a temporary certificate is
@@ -155,7 +157,8 @@ Adding the following annotation on an ingress will automatically set "issue-temp
  acme.cert-manager.io/http01-edit-in-place: "true"
  ```
 
-<h2 id="rotation-private-key">Rotation of the private key</h2>
+<a id="rotation-private-key"></a>
+## Rotation of the private key
 
 By default, the private key won't be rotated automatically. Using the setting
 `rotationPolicy: Always`, the private key Secret associated with a Certificate
@@ -201,7 +204,8 @@ spec:
  rotationPolicy: Always # 🔰 Here.
 ```
 
-<h3 id="actions-triggering-private-key-rotation">Actions that will trigger a rotation of the private key</h3>
+<a id="actions-triggering-private-key-rotation"></a>
+### Actions that will trigger a rotation of the private key
 
 Setting the `rotationPolicy: Always` won't rotate the private key immediately.
 In order to rotate the private key, the certificate objects must be reissued. A