Merge branch 'main' into manifest-index

.github/workflows/check-links.yaml

@@ -11,17 +11,17 @@ jobs:
   linkChecker:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@d632683dd7b4114ad314bca15554477dd762a938 # v4.2.0
+      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
 
       - name: Check unrendered links
         id: lychee_unrendered
-        uses: lycheeverse/lychee-action@2b973e86fc7b1f6b36a93795fe2c9c6ae1118621 # v1.10.0
+        uses: lycheeverse/lychee-action@7cd0af4c74a61395d455af97419279d86aafaede # v2.0.2
         env:
           GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
         with:
           fail: true
           debug: false
-          args: --no-progress --include-fragments --github-token ${{secrets.GITHUB_TOKEN}} -c lychee.toml -E content/
+          args: --no-progress --include-fragments --github-token ${{secrets.GITHUB_TOKEN}} --config config/lychee.toml -E content/
 
       # Deactivated. The --include-fragments flag is causing failures because rendered links
       # have a trailing '#' which is probably a result of the link style change plus the new
@@ -48,7 +48,7 @@ jobs:
 
       # - name: Check rendered links
       #   id: lychee_rendered
-      #   uses: lycheeverse/lychee-action@2b973e86fc7b1f6b36a93795fe2c9c6ae1118621 # v1.10.0
+      #   uses: lycheeverse/lychee-action@7cd0af4c74a61395d455af97419279d86aafaede # v2.0.2
       #   env:
       #     GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
       #   with:

README.md

@@ -41,6 +41,15 @@ hugo server
 
 By default, Hugo runs the website at: http://localhost:1313 and will re-build the site on changes.
 
+**Note for Github Codespaces User:** You will be required to install the hugo extended version. To do so download the extended version from [hugo release](https://github.com/gohugoio/hugo/releases) based on your operation system (mostly it is Ubuntu for Codespaces). Use the below commands to install and then move the hugo directory to `usr/local/hugo/bin/hugo`
+```
+wget https://github.com/gohugoio/hugo/releases/download/v0.135.0/hugo_extended_0.135.0_linux-amd64.deb
+sudo dpkg -i hugo_extended_0.135.0_linux-amd64.deb
+rm hugo_extended_0.135.0_linux-amd64.deb
+sudo mv /usr/local/bin/hugo /usr/local/hugo/bin/hugo
+```
+Finally, Check the hugo version by running: `hugo version`
+
 ## Update Docsy theme
 
 The project uses [Hugo Modules](https://gohugo.io/hugo-modules/) to manage the theme:
@@ -111,17 +120,38 @@ To create a new release branch:
 
 In the `main` branch:
 
-1. Update the versions list in [params.toml](/config/_default/params.toml) to add the next release.
+1. Add a new menu version corresponding to the new release branch in [params.toml](/config/_default/params.toml) that points to https://kyverno.io below these lines:
 
-2. Update `version_menu` and `version` in [params.toml](/config/_default/params.toml) for the next release.
+```toml
+# version_menu = "Versions"
+# Add your release versions here
+[[menu.versions]]
+  version = "1.8.0"
+  url = "https://release-1-8-0.kyverno.io"
+  weight = 1
+```
 
-3. Create a PR.
+and change the older release version entry to point to its own versioned url, so for example if adding 1.13:
 
-4. Clear the Netlify cache!
+```toml
+[[versions]] # New Line
+  version = "v1.13.0" # New Line
+  url = "https://kyverno.io" # New Line
+
+[[versions]]
+  version = "v1.12.0"
+  url = "https://release-1-12-0.kyverno.io" # Change this line
+```
+
+2. Clear the Netlify cache!
 
 In the current release branch:
 
-1. Update `params.toml` so that `version_menu` and `version` reflect the version of that release branch, NOT `main`. This is so when users navigate to the version of the docs represented in that version it shows the correct number.
+1. Do the same as above.
+
+2. Update `version` to the new release version. Following our example from above that would be `v1.13.0`.
+
+3. Update `version_menu` to the same release version.
 
 #### Submitting a PR to multiple release branches
 

config/_default/params.toml

@@ -9,7 +9,7 @@ showLineNumbers = false
 
 # Menu title if your navbar has a versions selector to access old versions of your site.
 # This menu appears only if you have at least one [versions] set.
-version_menu = "main"
+version_menu = "v1.13.0"
 
 # Flag used in the "version-banner" partial to decide whether to display a
 # banner on every page indicating that this is an archived version of the docs.
@@ -19,7 +19,7 @@ archived_version = false
 # The version number for the version of the docs represented in this doc set.
 # Used in the "version-banner" partial to display a version number for the
 # current doc set.
-version = "main"
+version = "v1.13.0"
 
 # A link to latest version of the docs. Used in the "version-banner" partial to
 # point people to the main doc site.
@@ -143,9 +143,13 @@ js = [
 # version_menu = "Versions"
 # Add your release versions here
 [[versions]]
-  version = "v1.12.0"
+  version = "v1.13.0"
   url = "https://kyverno.io"
 
+[[versions]]
+  version = "v1.12.0"
+  url = "https://release-1-12-0.kyverno.io"
+
 [[versions]]
   version = "v1.11.0"
   url = "https://release-1-11-0.kyverno.io"

content/en/_index.md

@@ -4,7 +4,7 @@ linkTitle = "Kyverno"
 +++
 
 {{< blocks/cover title="Kyverno" image_anchor="top" height="full" color="dark" >}}
-# Policy Management. Simplified. { class="text-center" }
+# Policy as Code, Simplified! { class="text-center" }
 
 <div class="mt-5 mx-auto">
 	<a class="btn btn-lg btn-primary mr-3 mb-4" href="#about-kyverno">
@@ -28,18 +28,19 @@ linkTitle = "Kyverno"
 <br/>
 
 <h2>
-Policy Management for Kubernetes and cloud native environments.
+The Kyverno project provides a comprehensive set of tools to manage the complete Policy-as-Code (PaC) lifecycle for Kubernetes and other cloud native environments
 </h2>
 <br/>
 
 <p style="line-height:1.5">
-Kyverno policies are declarative YAML resources and <b>no new language</b> is required to write policies. This allows using familiar tools such as <code style="font-size: 1.35rem">kubectl</code>, <code style="font-size: 1.35rem">git</code>, and <code style="font-size: 1.35rem">kustomize</code> to manage policies. For efficient handling of complex logic, Kyverno supports both JMESPath and the Common Expressions Language (CEL) languages. 
+
+Kyverno policies are declarative YAML resources and <b>no new language</b> is required. Kyverno enables use of familiar tools such as <code style="font-size: 1.35rem">kubectl</code>, <code style="font-size: 1.35rem">git</code>, and <code style="font-size: 1.35rem">kustomize</code> to manage policies. Kyverno supports JMESPath and the Common Expressions Language (CEL) for efficient handling of complex logic.
 
 In Kubernetes environments, Kyverno policies can <b>validate, mutate, generate, and cleanup</b> any Kubernetes resource, including custom resources. To help secure the software supply chain Kyverno policies can <b>verify OCI container image signatures and artifacts</b>. Kyverno policy reports and policy exceptions are also Kubernetes API resources.
 
-The **Kyverno CLI** can be used to apply and test policies off-cluster e.g., as part of a CI/CD pipeline. 
+The **Kyverno CLI** can be used to apply and test policies off-cluster e.g., as part of an IaC and CI/CD pipelines. 
 
-**Kyverno Policy Reporter**  provides in-cluster report management with a graphical web-based user interface. 
+**Kyverno Policy Reporter** provides report management with a graphical web-based user interface. 
 
 **Kyverno JSON** allows applying Kyverno policies in non-Kubernetes environments and on any JSON payload.
 

content/en/blog/general/assigning-node-metadata-to-pods/index.md

@@ -390,6 +390,9 @@ spec:
               # https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone
               topology.kubernetes.io/zone: "{{ ZoneLabel }}"
 ```
+### Credits
+
+Thanks to [Abir Sigron](https://github.com/abirsigron) for initiating the idea on Slack and conducting a POC.
 
 ## Closing
 

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

@@ -120,14 +120,14 @@ spec:
   template:
     spec:
       (containers[?securityContext == null]):
-        (len(@)): 0
+        (length(@)): 0
 ```
 
 In the assertion above, the first three fields `spec`, `template`, and `spec` are basic projections that simply take the content of their respective fields and pass that to descendants.
 
-`(containers[?securityContext == null])` is a JMESPath expression filtering the `containers` array, selecting only the element where `securityContext` is `null`. This projection results in a new array that is passed to the descendant (`(len(@))` in this case).
+`(containers[?securityContext == null])` is a JMESPath expression filtering the `containers` array, selecting only the element where `securityContext` is `null`. This projection results in a new array that is passed to the descendant (`(length(@))` in this case).
 
-`(len(@))` is another JMESPath expression that computes the length of the array. There's no more descendant at this point. We're at a leaf of the YAML tree and the array length we just computed is then compared against 0.
+`(length(@))` is another JMESPath expression that computes the length of the array. There's no more descendant at this point. We're at a leaf of the YAML tree and the array length we just computed is then compared against 0.
 
 If the comparison matches, the assertion will be considered valid; if not, it will be considered failed.