Source for: https://kyverno.io
This site makes use of the Docsy theme and Hugo Extended is required to render it.
To contribute changes, use the fork & pull approach.
1. First create a fork of the Kyverno website repository to your GitHub account. You will later created a PR (pull request using this fork.)
2. Next, create a local clone with the --recurse-submodules option:
git clone https://github.com/{GITHUB-ID}/website kyverno-website/ --recurse-submodules`3. Then navigate to the local folder and build the website for local viewing of changes:
cd kyverno-website
hugo server -vBy default, hugo runs the website at: http://localhost:1313 and will re-build the site on changes.
See render folder.
The Kyverno website has established several writing conventions in the interest of consistency and accuracy.
Active voice is preferred in most writing examples. Ex., "this ClusterPolicy mutates incoming Pods..." and not "incoming Pods are mutated by this ClusterPolicy".
- Kubernetes resource kinds are considered proper nouns and are distinguished from other nouns by the initial letter capitalization. Ex., "a Kubernetes Pod will be annotated".
- Anything intended to be proper code or typed at a CLI is formatting using Markdown code syntax with backticks or in blocks (surrounded by three backticks).
- Code represented in blocks should prefer a syntax declaration for this theme's highlighting ability. Ex., when displaying YAML notate the code block with three backticks and "yaml".
Here are the rules for managing release versions:
-
All fixes and feature changes go to the
main(we may in a few rare cases make fixes to prior versions of the documentation.) The main branch can be accessed athttps://main.kyverno.io. -
When a new release is ready for GA, a new release branch is created (see steps below). Release branches are named
release-{major}-{minor}-{patch}for examplerelease-1-4-2. The release branch can be accessed using the{branch}.kyverno.ioand the latest release is available atkyverno.io.
To create a new release branch:
-
Create and push the branch using
git checkout -b release-{major}-{minor}-{patch}or via GitHub. -
Update Netlify to point
productionto the new release.
In the main branch:
-
Update the versions list in config.toml to add the next release.
-
Update
version_menuandversionin params.toml for the next release. -
Create a PR.
Ideally all changes will go to main and then be promoted to a release branch. However, ocassionally we will need to fix documentation issues for already released versions. For such cases, a PR must be created for each release branch.
There are several ways to create multiple PRs, but here is one easy flow:
- Create a PR for the
mainbranch, as usual. - For each additional branch, checkout the branch (
git checkout <branch>), and then cherry pick the commit(s) to that branch usinggit --cherry-pick <commit>. - Submit PRs for each release branch.
Edit the .toml files inside the config/_default dir