refactor: supress usage of kustomize in build

[eddycharly]

Signed-off-by: Charles-Edouard Brétéché charles.edouard@nirmata.com

Explanation

This PR removes dependency to kustomize by not using it for creating helm chart CRDs, manifests, etc...

We maintain helm but not kustomize code so it's better to remove it from our build pipeline as it's going to become more and more obsolete.

[codecov]

Codecov Report

Merging #5691 (3e96649) into main (14d82cb) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #5691   +/-   ##
=======================================
  Coverage   34.64%   34.64%           
=======================================
  Files         190      190           
  Lines       21071    21071           
=======================================
  Hits         7300     7300           
  Misses      12961    12961           
  Partials      810      810           

Impacted Files	Coverage Δ
pkg/policy/generate/validate.go	22.03% <ø> (ø)

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[realshuting]

With the current changes, labels selector in the deployment will change and as it is immutable it will trigger the error below:

We need to add instructions on how to upgrade Kyverno while preserving all existing policies.

[eddycharly]

@realshuting label selector should not change with the latest commits.

[eddycharly]

I will update the PR

[realshuting]

Has anything changed regarding the release process?

run make codegen-install, it writes the install.yaml to config/install.yaml
run make codegen-helm-all, it updates Helm charts docs and CRDs

[eddycharly]

run make codegen-install is not necessary, I removed the yaml manifests from the repo, they will be generated on demand.

[realshuting]

make codegen-helm-crd is the only command needed for releasing 1.9.0+ correct? I will update the wiki accordingly.

[james-callahan]

Wait why was kustomize support removed?
It was so much nicer to use than helm for kyverno :/

[eddycharly]

Install manifests are available in release artifacts. Does this help ?

[james-callahan]

Install manifests are available in release artifacts. Does this help ?

No. To do a hashlocked kustomize build you want to be able to use a reference of github.com/kyverno/kyverno/config/someapp?ref=123456123456commithash123456123456

You also want the base kustomization to not have e.g. any namespaces

[eddycharly]

We also publish to oci. I think @stefanprodan uses that with kustomize in flux.

Another option is tu use helm to generate the manifests

[james-callahan]

We also publish to oci.

That's a helm thing; doesn't work with kustomize.

Another option is tu use helm to generate the manifests

The whole point here is avoiding helm...

[eddycharly]

We publish manifests to oci, not talking about the helm chart here.

[james-callahan]

We publish manifests to oci,

I'm not sure how that would be helpful?
With a kustomize remote reference https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/resource/ you have a few protocols available, but as far as I know nothing is suitable for fetching an image from an OCI filesystem bundle. https://github.com/hashicorp/go-getter#url-format

[stefanprodan]

@james-callahan see here an example of deploying Kyverno with Flux and Kustomize, using the OCI artifact and verifying its cosign signature are Flux features. https://github.com/fluxcd/flux2-multi-tenancy/tree/main/infrastructure/kyverno

[james-callahan]

@james-callahan see here an example of deploying Kyverno with Flux and Kustomize, using the OCI artifact and verifying its cosign signature are Flux features. https://github.com/fluxcd/flux2-multi-tenancy/tree/main/infrastructure/kyverno

• That requires people to use Flux (which we don't).
• It doesn't allow you to use the main feature of kustomize which is selective customisations to specific fields via overlays