The Helm backend has opt-in support for using Kubeconform as a validation tool for both Helm charts and deployments. This gives the extra confidence that the templates defined in the different charts are conformant to a Kubernetes version or specification, plus the addtional benefit of ensuring that their final version (when used in deployments) also meets that criteria.
To enable the usage of Kubeconform, first we need to activate the relevant backend in
[GLOBAL] backend_packages = [ ... "pants.backend.experimental.helm.check.kubeconform", ... ]
This will enable the
kubeconform subsystem in our workspace and enrich our
helm_deployment with common fields that can be used to fine tune Kubeconform's behaviour in each of our targets.
Extra documentation on
Enabling the backend will add the
kubeconformsubsystem in our workspace and enrich our
helm_deploymentwith common fields that can be used to fine tune Kubeconform's behaviour in each of our targets. Please run
pants help kubeconformas well as
pants help helm_chart/
pants help helm_deploymentafter enabling the backend to consult the different configuration settings.
After enabling the backend, we can run the
check goal in both
helm_deployment targets as we please:
❯ pants check ::
The check always happens in the rendered form of the Helm chart in question. In the case of
helm_chart targets, the chart will be rendered as has been defined, using the default companion
values.yml) file defined for the chart.
helm_deployment targets, the referenced chart will be rendered using the deployment sources and other settings like inline values, etc. This will also include all post-renderers defined for that given deployment (in case any has been defined). The effect this has is that running
pants check src/helm/mydeployment requires a bit more of work under the hood than checking a standalone chart.
You can use the
skip_kubeconform field in both
helm_deployment to prevent running it against a given target in case you consider it to be a redundant check.
Skipping check on publishable charts
On a workspace that contains both
helm_charttargets is easy to consider that checking the charts is a redundant task as doing it so on the deployment is effectively the same. This is a safe assumption as long as you don't publish your charts to be consumed elsewhere. For that specific case we recommend also checking the standalone chart as that gives assurance that the chart package itself is sound.
Regardless of that, running Kubeconform on a standalone chart is a pretty lightweight operation so unless you are facing extremelly long build times, better to not skip it.
Updated 2 months ago