Check links on PR; fix links (#1185)

* check links on PR

Signed-off-by: chipzoller <chipzoller@gmail.com>

* fix

Signed-off-by: chipzoller <chipzoller@gmail.com>

* fix base

Signed-off-by: chipzoller <chipzoller@gmail.com>

* new base

Signed-off-by: chipzoller <chipzoller@gmail.com>

* base as /content/en/docs/

Signed-off-by: chipzoller <chipzoller@gmail.com>

* base as /content/en/

Signed-off-by: chipzoller <chipzoller@gmail.com>

* base as https://kyverno.io

Signed-off-by: chipzoller <chipzoller@gmail.com>

* try with hugo building

Signed-off-by: chipzoller <chipzoller@gmail.com>

* npm install

Signed-off-by: chipzoller <chipzoller@gmail.com>

* use github token

Signed-off-by: chipzoller <chipzoller@gmail.com>

* use value

Signed-off-by: chipzoller <chipzoller@gmail.com>

* ignore rendered policies

Signed-off-by: chipzoller <chipzoller@gmail.com>

* glob

Signed-off-by: chipzoller <chipzoller@gmail.com>

* use lychee.toml

Signed-off-by: chipzoller <chipzoller@gmail.com>

* try

Signed-off-by: chipzoller <chipzoller@gmail.com>

* try

Signed-off-by: chipzoller <chipzoller@gmail.com>

* remove .lycheeignore

Signed-off-by: chipzoller <chipzoller@gmail.com>

* try new path to -c

Signed-off-by: chipzoller <chipzoller@gmail.com>

* try

Signed-off-by: chipzoller <chipzoller@gmail.com>

* simplify

Signed-off-by: chipzoller <chipzoller@gmail.com>

* add back .lycheeignore

Signed-off-by: chipzoller <chipzoller@gmail.com>

* fix two links

Signed-off-by: chipzoller <chipzoller@gmail.com>

* simplify

Signed-off-by: chipzoller <chipzoller@gmail.com>

* fixes

Signed-off-by: chipzoller <chipzoller@gmail.com>

* link fixes

Signed-off-by: chipzoller <chipzoller@gmail.com>

* fix links after CLI reorg

Signed-off-by: chipzoller <chipzoller@gmail.com>

* test

Signed-off-by: chipzoller <chipzoller@gmail.com>

* try

Signed-off-by: chipzoller <chipzoller@gmail.com>

* fix more links

Signed-off-by: chipzoller <chipzoller@gmail.com>

* use jakepartusch/wait-for-netlify-action@v1.4

Signed-off-by: chipzoller <chipzoller@gmail.com>

* update

Signed-off-by: chipzoller <chipzoller@gmail.com>

* reorder

Signed-off-by: chipzoller <chipzoller@gmail.com>

* enable Dependabot for Actions

Signed-off-by: chipzoller <chipzoller@gmail.com>

---------

Signed-off-by: chipzoller <chipzoller@gmail.com>

.github/dependabot.yml

@@ -0,0 +1,7 @@
+version: 2
+updates:
+  - package-ecosystem: github-actions
+    directory: /
+    schedule:
+      interval: daily
+    rebase-strategy: disabled

.github/workflows/check-links.yaml

@@ -3,20 +3,46 @@ name: Check Links
 on:
   repository_dispatch:
   workflow_dispatch:
+  pull_request:
+    branches:
+      - main
   schedule:
     - cron: "0 0 * * *"
 
 jobs:
   linkChecker:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v3
+      - name: Waiting for Netlify Preview
+        uses: jakepartusch/wait-for-netlify-action@f1e137043864b9ab9034ae3a5adc1c108e3f1a48 # v1.4
+        id: wait-for-netflify-preview
+        with:
+          site_name: kyverno
+          max_timeout: 60
+
+      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+
+      - name: Setup Hugo
+        uses: peaceiris/actions-hugo@16361eb4acea8698b220b76c0d4e84e1fd22c61d # v2.6.0
+        with:
+          hugo-version: latest
+          extended: true
+
+      - name: Install site dependencies
+        run: npm install --save-dev autoprefixer && npm install --save-dev postcss-cli && npm install -D postcss
+
+      - name: Build site with Hugo
+        run: hugo --minify -b ${{ steps.wait-for-netflify-preview.outputs.url }}
 
       - name: Link Checker
         id: lychee
-        uses: lycheeverse/lychee-action@v1.5.0
+        uses: lycheeverse/lychee-action@c053181aa0c3d17606addfe97a9075a32723548a # v1.9.3
         env:
           GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
+        with:
+          fail: true
+          debug: false
+          args: --no-progress --github-token ${{secrets.GITHUB_TOKEN}} -c lychee.toml -E public
 
       # - name: Create Issue From File
       #   if: steps.lychee.outputs.exit_code != 0

.lycheeignore

@@ -0,0 +1,5 @@
+https://github.com/kyverno/website/issues/*
+http://sodipodi.sourceforge.net*
+http://purl.org*
+https://github.com/kyverno/policies/openshift/
+gcpkms://*

content/en/blog/general/aws-irsa/index.md

@@ -6,7 +6,7 @@ author: Shuting Zhao
 description: "Using Kyverno to verify images with IRSA"
 ---
 
-When running workloads in Amazon Elastic Kubernetes Service (EKS), it is essential to ensure supply chain security by verifying container image signatures and other metadata. To achieve this, you can configure Kyverno, a CNCF policy engine designed for Kubernetes, to pull from ECR private registries for image verification. It's possible to [pass in the credentials via secrets](https://kyverno.io/docs/writing-policies/verify-images/sigstore/#using-private-registries), but that can get difficult to manage and automate across multiple clusters. In this blog post, we will explore an alternative method that simplifies the authentication process by leveraging Kyverno and IRSA (IAM Roles for Service Accounts) in EKS for image verification.
+When running workloads in Amazon Elastic Kubernetes Service (EKS), it is essential to ensure supply chain security by verifying container image signatures and other metadata. To achieve this, you can configure Kyverno, a CNCF policy engine designed for Kubernetes, to pull from ECR private registries for image verification. It's possible to [pass in the credentials via secrets](/docs/writing-policies/verify-images/sigstore/#using-private-registries), but that can get difficult to manage and automate across multiple clusters. In this blog post, we will explore an alternative method that simplifies the authentication process by leveraging Kyverno and IRSA (IAM Roles for Service Accounts) in EKS for image verification.
 
 Applications, such as Kyverno, running within a Pod's containers can utilize the AWS SDK to make API requests to AWS services by leveraging AWS Identity and Access Management (IAM) permissions. IAM roles for service accounts enable the management of credentials for these applications. Instead of manually creating and distributing AWS credentials to the containers, you can associate an IAM role with a Kubernetes service account and configure your Pods to utilize this service account. The detailed steps for this process can be found in the [documentation](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html). In this blog, we will guide you through the complete process of enabling IAM roles for the Kyverno service account and demonstrate how to verify this using the Kyverno `verifyImages` rule.
 
@@ -37,7 +37,7 @@ aws ec2 modify-instance-metadata-options --instance-id <instance-id> --http-toke
 
 ## Installing Kyverno
 
-Once you have the cluster set up, you can use Helm to [install Kyverno into the cluster](https://kyverno.io/docs/installation/methods/):
+Once you have the cluster set up, you can use Helm to [install Kyverno into the cluster](/docs/installation/methods/):
 
 ```sh
 helm upgrade --install kyverno kyverno/kyverno --namespace kyverno --create-namespace

content/en/blog/general/jmespath/index.md

@@ -10,20 +10,22 @@ The v1.9 release of Kyverno added several time related JMESPath filters. With th
 
 ## What is "JMESPath"?
 
-[JMESPath](https://jmespath.org/) (pronounced "James path") is a JSON query language that allows you to declaratively specify how to extract elements from a JSON document. It is similar to JSONPath in Kubernetes. It can be used almost anywhere in Kyverno. 
+[JMESPath](https://jmespath.org/) (pronounced "James path") is a JSON query language that allows you to declaratively specify how to extract elements from a JSON document. It is similar to JSONPath in Kubernetes. It can be used almost anywhere in Kyverno.
 
-Users may note that, many policies can be written with simple overlay patterns, others require more detailed selection and transformation. The latter is where JMESPath is useful. 
+Users may note that, many policies can be written with simple overlay patterns, others require more detailed selection and transformation. The latter is where JMESPath is useful.
 
-Kyverno supports all the JMESPath filters in the [JMESPath specifications page](https://jmespath.org/specification.html) and also adds several custom filters. Refer to [Kyverno's JMESPath docs](https://main.kyverno.io/docs/writing-policies/jmespath/) for a comprehensive deep dive.
+Kyverno supports all the JMESPath filters in the [JMESPath specifications page](https://jmespath.org/specification.html) and also adds several custom filters. Refer to [Kyverno's JMESPath docs](/docs/writing-policies/jmespath/) for a comprehensive deep dive.
 
 ## Why did we need these new filters?
-Kyverno already supports all the availible filters in the upstream JMESpath library and some custom filters as well. But there was a lack of time related filters that come in useful at several places in Kyverno, such as 
+
+Kyverno already supports all the available filters in the upstream JMESPath library and some custom filters as well. But there was a lack of time related filters that come in useful at several places in Kyverno, such as
 
 1. When we want to add custom labels like last sync time.
 2. Enforce a policy that checks whether the current time is after or before a specified time.
 3. Perform job scheduling using cron expressions.
 
 ## What has been added?
+
 In v1.9 release, Kyverno added 11 new time related filters to fulfill the above requirements and many more as well.
 
 1. **Time_add:** We have added a filter to do arithmetic addition of a duration to a given time. The `time_add()` filter takes a time and a duration and returns a time. `time_add('2023-01-12T12:37:56-05:00','6h')` results in the value `"2023-01-12T18:37:56-05:00"`. It can come in useful purposes like adding some time to the current time and passing it as an argument for other time related filters.
@@ -39,7 +41,9 @@ In v1.9 release, Kyverno added 11 new time related filters to fulfill the above
 11. **Time_utc:** The `time_utc()` filter takes in a time in RFC 3339 format with a time offset and presents the same time in UTC/Zulu. It can be used in pair with `time_parse()` to convert it to UTC.
 
 ## How to use it?
-An in-depth guide on how to use JMESPath filters in kyverno is present in the [Kyverno's JMESPath docs](https://main.kyverno.io/docs/writing-policies/jmespath/). 
+
+An in-depth guide on how to use JMESPath filters in kyverno is present in the [Kyverno's JMESPath docs](/docs/writing-policies/jmespath/).
+
 ## Summary
 
-JMESPath is a powerful and robust tool for selecting, extracting and manipulating time in JSON. With the addition of the new time based filters, we have extended the capabilitites of JMES filters in kyverno and have opened new usecases.
+JMESPath is a powerful and robust tool for selecting, extracting and manipulating time in JSON. With the addition of the new time based filters, we have extended the capabilities of JMES filters in kyverno and have opened new usecases.

content/en/blog/general/slsa-3/index.md

@@ -154,7 +154,7 @@ The GitHub Action reusable workflow hosted by the SLSA GitHub Generator project
 The build service's users can not falsify the provenance.
 
 **Kyverno Processes:**
-GitHub takes care of avoiding interference with the build system. GitHub uses ephemeral and isolated virtual machines, no one can persistently compromise this environment. GitHub automatically provisions a new VM for that job. When the job execution is finished, the VM is automatically decommissioned. Use of the [SLSA GitHub generator](https://github.com/slsa-framework/slsa-github-generator) separates the signing from building so the Kyverno build itself never has access to the signing secrets. Use of OIDC-based secrets through Sigstore's [keyless signing](https://github.com/sigstore/cosign/blob/main/KEYLESS.md) means the ephemeral signing secret is associated only with one specific build making it easy to detect secret theft and an attempt at signing something else.
+GitHub takes care of avoiding interference with the build system. GitHub uses ephemeral and isolated virtual machines, no one can persistently compromise this environment. GitHub automatically provisions a new VM for that job. When the job execution is finished, the VM is automatically decommissioned. Use of the [SLSA GitHub generator](https://github.com/slsa-framework/slsa-github-generator) separates the signing from building so the Kyverno build itself never has access to the signing secrets. Use of OIDC-based secrets through Sigstore's [keyless signing](https://docs.sigstore.dev/signing/overview/) means the ephemeral signing secret is associated only with one specific build making it easy to detect secret theft and an attempt at signing something else.
 
 ### Provenance Content Requirements
 

content/en/blog/general/using-cel-expressions-in-kyverno-policies/index.md

@@ -20,7 +20,7 @@ A policy consists of different clauses, such as:
 - Generate: It creates additional resources.
 - Verify Images: It verifies container image signatures using Cosign and Notary.
 
-Refer to [Selecting Resources](https://kyverno.io/docs/writing-policies/match-exclude/) for more information.
+Refer to [Selecting Resources](/docs/writing-policies/match-exclude/) for more information.
 
 > Each rule can contain only a single validate, mutate, generate, or verifyImages child declaration.
 
@@ -550,7 +550,7 @@ deployment.apps/deployment-pass created
 
 Since Kubernetes has many higher-level controllers that directly or indirectly manage Pods: Deployment, DaemonSet, StatefulSet, Job, and CronJob resources, it’d be inefficient to write a policy that targets Pods and every higher-level controller. Kyverno solves this issue by supporting the automatic generation of policy rules for higher-level controllers from a rule written exclusively for a Pod. 
 
-Check the [autogen rules](https://kyverno.io/docs/writing-policies/autogen/) for more information.
+Check the [autogen rules](/docs/writing-policies/autogen/) for more information.
 
 For example, when creating a validation policy like below, which disallows latest image tags, the policy applies to all resources capable of generating Pods.
 

content/en/blog/general/why-chainsaw-is-unique/index.md

@@ -189,7 +189,7 @@ Now we can use the binding to write an assertion check taking the pod-level secu
 
 We covered all major features of assertion trees in this blog post.
 
-Chainsaw doesn't directly implement assertion trees but relies on the [kyverno-json package](https://github.com/kyverno/kyverno-json). You can browse [the documentation](https://kyverno.github.io/kyverno-json/policies/asserts/#assertion-trees) to learn more about assertion trees, this documentation also applies to Chainsaw. The [kyverno-json playground](https://kyverno.github.io/kyverno-json/_playground/) is also a good resource to familiarise with assertion trees.
+Chainsaw doesn't directly implement assertion trees but relies on the [kyverno-json package](https://github.com/kyverno/kyverno-json). You can browse [the documentation](https://kyverno.github.io/kyverno-json/latest/policies/asserts/#assertion-trees) to learn more about assertion trees, this documentation also applies to Chainsaw. The [kyverno-json playground](https://kyverno.github.io/kyverno-json/latest/_playground/) is also a good resource to familiarise with assertion trees.
 
 Note that JMESPath supports functions and also allows custom functions to be registered in the JMESPath interpreter. The supported list of functions is available [here](https://kyverno.github.io/chainsaw/latest/jp/functions/).
 

content/en/docs/Applying Policies/_index.md

@@ -25,6 +25,6 @@ Exceptions to policies may be defined in the rules themselves or with a separate
 
 ## In Pipelines
 
-You can use the [Kyverno CLI](/docs/kyverno-cli/#apply) to apply policies to YAML resource manifest files as part of a software delivery pipeline. This command line tool allows integrating Kyverno into GitOps style workflows and checks for policy compliance of resource manifests before they are committed to version control and applied to clusters.
+You can use the [Kyverno CLI](/docs/kyverno-cli/usage/apply/) to apply policies to YAML resource manifest files as part of a software delivery pipeline. This command line tool allows integrating Kyverno into GitOps style workflows and checks for policy compliance of resource manifests before they are committed to version control and applied to clusters.
 
-Refer to the [Kyverno apply command section](/docs/kyverno-cli/#apply) for details on the CLI. And refer to the [Continuous Integration section](/docs/testing-policies/#continuous-integration) for an example of how to incorporate the CLI to apply and test policies in your pipeline.
+Refer to the [Kyverno apply command section](/docs/kyverno-cli/usage/apply/) for details on the CLI. And refer to the [Continuous Integration section](/docs/testing-policies/#continuous-integration) for an example of how to incorporate the CLI to apply and test policies in your pipeline.

content/en/docs/Installation/_index.md

@@ -53,7 +53,7 @@ Kyverno follows the same support policy as the Kubernetes project which is an N-
 
 \* Due to a known issue with Kubernetes 1.23.0-1.23.2, support for 1.23 begins at 1.23.3.
 
-**NOTE:** The [Enterprise Kyverno](https://nirmata.com/kyverno-enterprise/) by Nirmata supports a wide range of Kubernetes versions for any Kyverno version. Refer to the Release Compatibility Matrix for the Enterprise Kyverno [here](https://docs.nirmata.io/n4k/release-compatibility-matrix/) or contact [Nirmata support](mailto:support@nirmata.com) for assistance.
+**NOTE:** The [Enterprise Kyverno](https://nirmata.com/kyverno-enterprise/) by Nirmata supports a wide range of Kubernetes versions for any Kyverno version. Refer to the Release Compatibility Matrix for the Enterprise Kyverno [here](https://docs.nirmata.io/docs/n4k/release-compatibility-matrix/) or contact [Nirmata support](mailto:support@nirmata.com) for assistance.
 
 ## Security vs Operability
 

content/en/docs/Kyverno CLI/reference/kyverno.md

@@ -18,7 +18,7 @@ Kubernetes Native Policy Management.
 
   NOTE: To enable experimental commands, environment variable "KYVERNO_EXPERIMENTAL" should be set true or 1.
 
-  For more information visit https://kyverno.io/docs/kyverno-cli
+  For more information visit [here](/docs/kyverno-cli)
 
 ```
 kyverno [flags]

content/en/docs/Kyverno CLI/reference/kyverno_apply.md

@@ -11,7 +11,7 @@ Applies policies on resources.
 
 Applies policies on resources.
 
-  For more information visit https://kyverno.io/docs/kyverno-cli/#apply
+  For more information visit [here](/docs/kyverno-cli/usage/apply/)
 
 ```
 kyverno apply [flags]

content/en/docs/Kyverno CLI/reference/kyverno_jp.md

@@ -11,7 +11,7 @@ Provides a command-line interface to JMESPath, enhanced with Kyverno specific cu
 
 Provides a command-line interface to JMESPath, enhanced with Kyverno specific custom functions.
 
-  For more information visit https://kyverno.io/docs/kyverno-cli/#jp
+  For more information visit [here](/docs/kyverno-cli/usage/jp/)
 
 ```
 kyverno jp [flags]

content/en/docs/Kyverno CLI/reference/kyverno_jp_function.md

@@ -11,7 +11,7 @@ Provides function informations.
 
 Provides function informations.
 
-  For more information visit https://kyverno.io/docs/kyverno-cli/#jp
+  For more information visit [here](/docs/kyverno-cli/usage/jp/)
 
 ```
 kyverno jp function [function_name]... [flags]

content/en/docs/Kyverno CLI/reference/kyverno_jp_parse.md

@@ -11,7 +11,7 @@ Parses jmespath expression and shows corresponding AST.
 
 Parses jmespath expression and shows corresponding AST.
 
-  For more information visit https://kyverno.io/docs/kyverno-cli/#jp
+  For more information visit [here](/docs/kyverno-cli/usage/jp/)
 
 ```
 kyverno jp parse [-f file|expression]... [flags]

content/en/docs/Kyverno CLI/reference/kyverno_jp_query.md

@@ -11,7 +11,7 @@ Provides a command-line interface to JMESPath, enhanced with Kyverno specific cu
 
 Provides a command-line interface to JMESPath, enhanced with Kyverno specific custom functions.
 
-  For more information visit https://kyverno.io/docs/kyverno-cli/#jp
+  For more information visit [here](/docs/kyverno-cli/usage/jp/)
 
 ```
 kyverno jp query [-i input] [-q query|query]... [flags]

content/en/docs/Kyverno CLI/reference/kyverno_test.md

@@ -17,7 +17,7 @@ Run tests from a local filesystem or a remote git repository.
   Users provide the path to the folder containing a kyverno-test.yaml file where the location could be
   on a local filesystem or a remote git repository.
 
-  For more information visit https://kyverno.io/docs/kyverno-cli/#test
+  For more information visit [here](/docs/kyverno-cli/usage/test/)
 
 ```
 kyverno test [local folder or git repository]... [flags]

content/en/docs/Kyverno CLI/reference/kyverno_version.md

@@ -11,7 +11,7 @@ Prints the version of Kyverno CLI.
 
 Prints the version of Kyverno CLI.
 
-  For more information visit https://kyverno.io/docs/kyverno-cli/#version
+  For more information visit [here](/docs/kyverno-cli/usage/)
 
 ```
 kyverno version [flags]

content/en/docs/Kyverno CLI/usage/test.md

@@ -65,7 +65,7 @@ The test declaration consists of the following parts:
 5. The `userinfo` element which declares admission request data for subjects and roles. Optional depending on policy content.
 6. The `results` element which declares the expected results. Depending on the type of rule being tested, this section may vary.
 
-If needing to pass variables, such as those from [external data sources](/docs/writing-policies/external-data-sources/) like context variables built from [API calls](https://kyverno.io/docs/writing-policies/external-data-sources/#variables-from-kubernetes-api-server-calls) or others, a `variables.yaml` file can be defined with the same format as accepted with the `apply` command. If a variable needs to contain an array of strings, it must be formatted as JSON encoded. Like with the `apply` command, variables that begin with `request.object` normally do not need to be specified in the variables file as these will be sourced from the resource. Policies which trigger based upon `request.operation` equaling `CREATE` do not need a variables file. The CLI will assume a value of `CREATE` if no variable for `request.operation` is defined.
+If needing to pass variables, such as those from [external data sources](/docs/writing-policies/external-data-sources/) like context variables built from [API calls](/docs/writing-policies/external-data-sources/#variables-from-kubernetes-api-server-calls) or others, a `variables.yaml` file can be defined with the same format as accepted with the `apply` command. If a variable needs to contain an array of strings, it must be formatted as JSON encoded. Like with the `apply` command, variables that begin with `request.object` normally do not need to be specified in the variables file as these will be sourced from the resource. Policies which trigger based upon `request.operation` equaling `CREATE` do not need a variables file. The CLI will assume a value of `CREATE` if no variable for `request.operation` is defined.
 
 ```yaml
 apiVersion: cli.kyverno.io/v1alpha1