Kubeconform
Overview
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 pants.toml
:
[GLOBAL]
backend_packages = [
...
"pants.backend.experimental.helm.check.kubeconform",
...
]
This will enable the kubeconform
subsystem in our workspace and enrich our helm_chart
and helm_deployment
with common fields that can be used to fine tune Kubeconform's behaviour in each of our targets.
kubeconform
Enabling the backend will add the kubeconform
subsystem in our workspace and enrich our helm_chart
and helm_deployment
with common fields that can be used to fine tune Kubeconform's behaviour in each of our targets. Please run pants help kubeconform
as well as pants help helm_chart
/pants help helm_deployment
after enabling the backend to consult the different configuration settings.
Validating charts and deployments
After enabling the backend, we can run the check
goal in both helm_chart
and 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.yaml
(or values.yml
) file defined for the chart.
For 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_chart
or helm_deployment
to prevent running it against a given target in case you consider it to be a redundant check.
On a workspace that contains both helm_deployment
and helm_chart
targets 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.