Package: helmYAMLizer
helmYAMLizerAdopting a minimalistic approach to rendering multi-document YAML produced by thehelm templateoutput into local
files. In line with GitOps practices, a shallow or non-nested structure for saved YAML is preferred to ensure better
visibility and clarity.Users can choose to leave out certain labels from the generated YAML. For instance, they might decide not to include
theapp.kubernetes.io/managed-by: Helmlabel. They also have the ability to generate akustomization.yamlfile,
which will list all the processed HELM chart YAML files as resources../helmYAMLizer.py --help
usage: helmYAMLizer.py [-h] -d DIR [--drop-label-keys [DROP_LABEL_KEYS ...]] [-k] [--debug]

options:
  -h, --help            show this help message and exit
  -d DIR, --dir DIR     The directory where files will be saved.
  --drop-label-keys [DROP_LABEL_KEYS ...]
                        List of metadata label keys to remove.
  -k, --kustomize-generate
                        Should we generate a kustomize file?
  --debug               Should we run the script in debug mode?Usage# helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx && helm repo updatepipinstallhelmYAMLizer
helmtemplateingress-nginx/ingress-nginx|helmYAMLizer--dir'nginx'With docker image:# helm repo add prometheus-community https://prometheus-community.github.io/helm-charts && helm repo updatedockerpullghcr.io/violetcranberry/helmyamlizer:latest&&mkdirprom-stack

helmtemplateprometheus-community/kube-prometheus-stack|\dockerrun-iv$(pwd)/prom-stack:/prom-stackghcr.io/violetcranberry/helmyamlizer:latest\--dir'prom-stack'With shell:# helm repo add gloo https://storage.googleapis.com/solo-public-helm && helm repo updatepipinstallruamel.yaml
helmtemplate--include-crdsgloo/gloo|\python<(curl-sLhttps://raw.githubusercontent.com/VioletCranberry/helmYAMLizer/main/helmYAMLizer.py)\--dir'gloo'Demo:For additional examples, refer to theexamplesdirectory.The problemAdvocates of immutable infrastructure often favorKustomizeoverHelmbecause of its strictly declarative nature, stable configurations,
independence from chart repositories, and lack of a templating system. Yet, not all chart creators offer resources
in Kustomize-friendly formats. In such instances, the only alternative might be thehelm templatecommand.The strategyThe HelmRenderSourcesfunction responsible
for templating, tags the source of rendered templates with#Source: <yaml_path>. In the resulting multi-document YAML,
each YAML document is demarcated by---followed by the template's origin / source comment.The complete multi-document YAML is seen as a sequence of dictionaries. Each of these begins with---,
followed by ahelm templatesource comment. This comment reveals the location for the related chart template.
From this source comment, we can determine the absolute location for a specific document. TheRenderSourcesfunction
also guides us in shaping the final structure:If the path commences withcrds/, it remains unchanged.If the path contains/templates/, only the part after this segment is returned. This ensures no extra folders are
created while still preserving any existing nested structure, if present.helm templateissuesThehelm templatecommand can sometimes produce incorrect YAML, given its inherent delimiters and lack of validation.
This might result in the generation of blank or incorrect YAML sections. For instance, an empty YAML document might
appear sandwiched between two legitimate ones, or documents may be incomplete.In these situations, consistently generating dependable YAML becomes difficult since we can't always rely on source
comments for validation and path creation. If there are sections of problematic YAML, users will be alerted with a
warning.In the context of using thehelm templatecommand with the--output-dirparameter, the resultant output creates a
deeply-nested hierarchy of rendered templates, charts, and their associated CRDs. This intricate structure compromises
clarity and visibility, making it challenging to swiftly locate and access the intended resources.Dependenciesruamel.yaml- serves as a versatile alternative to PyYAML, offering advantages
like comment preservation, key order retention, and compatibility with the YAML 1.2 specification, as opposed to PyYAML's
limited compatibility with YAML 1.1.