docs: Flat directory structure in public as sub directories caused li…

…nk issues

Signed-off-by: Peter Fiddes <[email protected]>

content/docs/tutorials/certificate-defaults/README.md

@@ -156,14 +156,14 @@ These fields are:
 
 1. Let's first take a look at the `ClusterPolicy`:
 
-    ```yaml file=../../../../public/docs/tutorials/certificate-defaults/yamls/cpol-mutate-certificate-defaults.yaml
+    ```yaml file=../../../../public/docs/tutorials/certificate-defaults/cpol-mutate-certificate-defaults.yaml
     ```
-    🔗 <a href="yamls/cpol-mutate-certificate-defaults.yaml">`cpol-mutate-certificate-defaults.yaml`</a>
+    🔗 <a href="cpol-mutate-certificate-defaults.yaml">`cpol-mutate-certificate-defaults.yaml`</a>
 
 1. Apply the policy to the cluster and check that it is ready:
 
     ```shell
-    kubectl apply -f yamls/cpol-mutate-certificate-defaults.yaml
+    kubectl apply -f cpol-mutate-certificate-defaults.yaml
     kubectl get cpol
     ```
 
@@ -176,16 +176,16 @@ These fields are:
 
 1. Now inspect the `Certificate` for testing with the name "test-revision":
 
-    ```yaml file=../../../../public/docs/tutorials/certificate-defaults/yamls/cert-test-revision.yaml
+    ```yaml file=../../../../public/docs/tutorials/certificate-defaults/cert-test-revision.yaml
     ```
-    🔗 <a href="yamls/cert-test-revision.yaml">`cert-test-revision.yaml`</a>
+    🔗 <a href="cert-test-revision.yaml">`cert-test-revision.yaml`</a>
 
     You can see that we have set the most minimal configuration currently possible, specifying only a DNS name for the certificate, where to save it (`secretName`) and the issuer to use to request the certificate (`issuerRef`).
 
 1. Use the following command to dry-run apply the certificate and then `diff` it against the original resource, to see how the defaults from our `ClusterPolicy` are applied:
 
     ```shell
-    kubectl apply -f yamls/cert-test-revision.yaml --dry-run=server -o yaml | diff -uZ yamls/cert-test-revision.yaml -
+    kubectl apply -f cert-test-revision.yaml --dry-run=server -o yaml | diff -uZ cert-test-revision.yaml -
     ```
 
     The output should look similar to this:
@@ -230,14 +230,14 @@ These fields are:
 
 1. Let's override all of these defaulted fields, to validate that we can still set what we want as an end user. Here is a new `Certificate` resource to use for testing called "test-revision-override":
 
-    ```yaml file=../../../../public/docs/tutorials/certificate-defaults/yamls/cert-test-revision-override.yaml
+    ```yaml file=../../../../public/docs/tutorials/certificate-defaults/cert-test-revision-override.yaml
     ```
-    🔗 <a href="yamls/cert-test-revision-override.yaml">`cert-test-revision-override.yaml`</a>
+    🔗 <a href="cert-test-revision-override.yaml">`cert-test-revision-override.yaml`</a>
 
     As before, dry-run apply and diff the output with the input file:
 
     ```shell
-    kubectl apply -f yamls/cert-test-revision-override.yaml --dry-run=server -o yaml | diff -uZ yamls/cert-test-revision-override.yaml -
+    kubectl apply -f cert-test-revision-override.yaml --dry-run=server -o yaml | diff -uZ cert-test-revision-override.yaml -
     ```
 
     Here you can see in the output there are no specification changes for the `Certificate` itself. You can see that the `ClusterPolicies` have been considered, but no action taken. This is visable from the annotations added by Kyverno:
@@ -279,14 +279,14 @@ In our example `ClusterPolicy` we will do two things:
 
 1. Here is the `ClusterPolicy` resource to set both fields with defaults:
 
-    ```yaml file=../../../../public/docs/tutorials/certificate-defaults/yamls/cpol-mutate-certificate-required.yaml
+    ```yaml file=../../../../public/docs/tutorials/certificate-defaults/cpol-mutate-certificate-required.yaml
     ```
-    🔗 <a href="yamls/cpol-mutate-certificate-required.yaml">`cpol-mutate-certificate-required.yaml`</a>
+    🔗 <a href="cpol-mutate-certificate-required.yaml">`cpol-mutate-certificate-required.yaml`</a>
 
 1. Apply this policy:
 
     ```shell
-    kubectl apply -f yamls/cpol-mutate-certificate-required.yaml
+    kubectl apply -f cpol-mutate-certificate-required.yaml
     ```
 
 1. Patch the previous policy we applied, to disable schema validation after mutation:
@@ -302,20 +302,20 @@ In our example `ClusterPolicy` we will do two things:
 
 1. Take a look at another new `Certificate` we have for validating that all our policies will now take effect. This time called "test-minimal":
 
-    ```yaml file=../../../../public/docs/tutorials/certificate-defaults/yamls/cert-test-minimal.yaml
+    ```yaml file=../../../../public/docs/tutorials/certificate-defaults/cert-test-minimal.yaml
     ```
-    🔗 <a href="yamls/cert-test-minimal.yaml">`cert-test-minimal.yaml`</a>
+    🔗 <a href="cert-test-minimal.yaml">`cert-test-minimal.yaml`</a>
 
 1. Dry run apply and `diff` to validate all our defaults have applied to this minimal `Certificate`:
 
     ```shell
-    kubectl apply -f yamls/cert-test-minimal.yaml --dry-run=server -o yaml | diff -uZ yamls/cert-test-minimal.yaml -
+    kubectl apply -f cert-test-minimal.yaml --dry-run=server -o yaml | diff -uZ cert-test-minimal.yaml -
     ```
 
     An example succesful output:
 
     ```yaml
-    --- yamls/cert-test-minimal.yaml	2023-09-07 16:58:44.979597651 +0100
+    --- cert-test-minimal.yaml	2023-09-07 16:58:44.979597651 +0100
     +++ -	2023-09-08 11:05:44.122807372 +0100
     @@ -1,8 +1,31 @@
     apiVersion: cert-manager.io/v1
@@ -355,20 +355,20 @@ In our example `ClusterPolicy` we will do two things:
 
 1. To be absolutely sure we have not enforced any settings, let us try and set every value of the `Certificate` explicitly, that we have a default rule for. We will use a final `Certificate` named "test-revision-override":
 
-    ```yaml file=../../../../public/docs/tutorials/certificate-defaults/yamls/cert-test-revision-override.yaml
+    ```yaml file=../../../../public/docs/tutorials/certificate-defaults/cert-test-revision-override.yaml
     ```
-    🔗 <a href="yamls/cert-test-revision-override.yaml">`cert-test-revision-override.yaml`</a>
+    🔗 <a href="cert-test-revision-override.yaml">`cert-test-revision-override.yaml`</a>
 
 1. Dry-run apply and `diff` this file:
 
     ```shell
-    kubectl apply -f yamls/cert-test-revision-override.yaml --dry-run=server -o yaml | diff -uZ yamls/cert-test-revision-override.yaml -
+    kubectl apply -f cert-test-revision-override.yaml --dry-run=server -o yaml | diff -uZ cert-test-revision-override.yaml -
     ```
 
     This should return:
 
     ```yaml
-    --- yamls/cert-test-revision-override.yaml	2023-09-07 16:58:41.363648093 +0100
+    --- cert-test-revision-override.yaml	2023-09-07 16:58:41.363648093 +0100
     +++ -	2023-09-08 11:09:16.026674875 +0100
     @@ -1,8 +1,14 @@
     apiVersion: cert-manager.io/v1
@@ -399,14 +399,14 @@ Let's see how we can still use `ClusterPolicy` to apply our defaults in this use
 
 1. Check the example `Ingress` resource has the correct annotation to select an `Issuer` or `ClusterIssuer`:
 
-    ```yaml file=../../../../public/docs/tutorials/certificate-defaults/yamls/ingress.yaml
+    ```yaml file=../../../../public/docs/tutorials/certificate-defaults/ingress.yaml
     ```
-    🔗 <a href="yamls/ingress.yaml">`ingress.yaml`</a>
+    🔗 <a href="ingress.yaml">`ingress.yaml`</a>
 
 1. This annotation and the relevant `ingress.spec.tls` configuration is all we need:
 
     ```shell
-    kubectl apply -f yamls/ingress.yaml
+    kubectl apply -f ingress.yaml
     ```
 
 1. Now validate that the `Certificate` resource was automatically generated:
@@ -491,15 +491,15 @@ We've shown how a `ClusterPolicy` doesn't have to "enforce" settings, rather it
 
 We have shown how a few simple policies can change the user experience creating `Certificate` resources from:
 
-```yaml file=../../../../public/docs/tutorials/certificate-defaults/yamls/cert-test-revision-override.yaml
+```yaml file=../../../../public/docs/tutorials/certificate-defaults/cert-test-revision-override.yaml
 ```
-🔗 <a href="yamls/cert-test-revision-override.yaml">`cert-test-revision-override.yaml`</a>
+🔗 <a href="cert-test-revision-override.yaml">`cert-test-revision-override.yaml`</a>
 
 To instead only need to specify the configuration important to them, for example:
 
-```yaml file=../../../../public/docs/tutorials/certificate-defaults/yamls/cert-test-minimal.yaml
+```yaml file=../../../../public/docs/tutorials/certificate-defaults/cert-test-minimal.yaml
 ```
-🔗 <a href="yamls/cert-test-minimal.yaml">`cert-test-minimal.yaml`</a>
+🔗 <a href="cert-test-minimal.yaml">`cert-test-minimal.yaml`</a>
 
 With these policies we achieved our objective and have enabled users to submit minimal `Certifiate` resources, with only a single field contained within the specification, the `dnsNames` entry.
 Every other specified field was automatically defaulted using Kyverno with `ClusterPolicy` which would typically be setup by a platform administrator.
@@ -553,9 +553,9 @@ Option 3 defeats the point of allowing a user to override when needed, so discou
 Option 2 is recommended, as this is the fix that is implemented in later versions of cert-manager, based on [PR #6311](https://github.com/cert-manager/cert-manager/pull/6311).
 To manually patch the webhook we have a YAML patch resource:
 
-```yaml file=../../../../public/docs/tutorials/certificate-defaults/patches/mutatingwebhookconfiguration-patch.yaml
+```yaml file=../../../../public/docs/tutorials/certificate-defaults/mutatingwebhookconfiguration-patch.yaml
 ```
-🔗 <a href="patches/mutatingwebhookconfiguration-patch.yaml">`mutatingwebhookconfiguration-patch.yaml`</a>
+🔗 <a href="mutatingwebhookconfiguration-patch.yaml">`mutatingwebhookconfiguration-patch.yaml`</a>
 
 To validate exactly what this patch will do, simply run the following to see a `kubectl diff`: