Most of the code is in go templates: helmfile's
*.gotmpl and helm chart's
templates/*.yaml. Please become familiar with it's intricacies by reading our special section on go templating.
For editing the
values-schema.yaml please refer to the meta-schema documentation.
For working with
bats and adding tests to
bin/tests/* please refer to the online bats documentation
You can define OPA policies in
policies/*/src.rego and unit tests in
policies/*/src_test.rego files that are used both for statical analysis (also at build time), as well as by gatekeeper (at run time) to check whether manifests are conformant. Please read more about our setup in the docs.
For the next steps you will need to export
ENV_DIR to point to your values folder, and source the aliases:
Start by validating the configuration values against the
Any changes made to the meta-schema will then also be automatically validated.
You can check whether resulting manifests are conform our specs with:
This will check whether any CRs are matching their CRDs, but also check for k8s manifest best practices using kubeval.
And to run the policy checks run the following:
To test changes in code against running clusters you will need to export at least
CLUSTER and source the aliases:
After changing code you can do a diff to see everything still works and what has changed in the output manifests:
It is preferred that deployment is done from the values repo, as it is tied to the clusters listed there only, and thus has a smaller blast radius. When you feel that you are in control and want fast iteration you can connect to a values repo directly by exporting
ENV_DIR. It is mandatory and won't work without it. The CLI will also check that you are targeting
current-context as a failsafe mechanism.
To deploy everything in the stack:
NOTICE: when on GKE this may sometimes result in an access token refresh error as the full path to the
gcloud binary is referenced from GKE's token refresh mechanism in
.kube/config, which is mounted from the host, but inaccessible from within the container. (See bug report: https://issuetracker.google.com/issues/171493249). Retrying the command usuall works, so do that to work around it for now.
It is also possible to target individual helmfile releases from the stack:
This will first do a
diff and then a
sync. But if you expect the helm bookkeeping to not match the current state (because resources were manipulated without helm), then do a sync: