This change allows to create ConfigMaps from files inside of a base folder in the repo
Added
Added a new "bjw-s.common.render.configMaps.fromFiles" template that gets all "first-level" folders under .Values.configMapsFromFolderBasePath and creates a ConfigMap with all the files within that folder
Benefits
This should help keeping the values.yaml a little smaller and easier to read by letting you have the contents of your ConfigMaps (or, at least, of the ConfigMaps that include bigger files) under a separate path. You can focus on adding and editing your files with any tool you like and, as long as they are sitting in your selected folder, not have to worry about adding them to your .Values.ConfigMaps.
There might be cases where you don't want Helm to template the data of your ConfigMap (e.g with Jinja templating), so you can rename your file to {something}.escape.{something} and it won't try to do that. This will also strip the .escape section from your key when creating the ConfigMap.
Possible drawbacks
I haven't thought of an ellegant way of passing down labels and annotations for these ConfigMaps, so they will just inherit the global ones
So far I've only used it with relatively small and simple files (mostly for scripts and config files), I haven't tested this with big files, or with a syntax so complex that can cause the Helm template to change the contents of the file in a meaningful way.
The template alway needs to be called beforebjw-s.common.render.configMaps in the _generate.tpl file, otherwise it won't work (more information on this below)
Additional information
I wanted to keep this DRY whithout losing on the advantages that the chart already gives while creating ConfigMaps from values. So I thought that, instead of differentiating between ConfigMaps declared in the values and ConfigMaps loaded from the repo, it would be better to just build the configMapValues from the files and inject them into .Values.configMaps before bjw-s.common.render.configMaps gets called. This way if the ConfigMap comes from the values or from the filesystem it will be transparent to the chart.
Description of the change
This change allows to create ConfigMaps from files inside of a
base folderin the repoAdded
Added a new "bjw-s.common.render.configMaps.fromFiles" template that gets all "first-level" folders under
.Values.configMapsFromFolderBasePathand creates aConfigMapwith all the files within that folderBenefits
values.yamla little smaller and easier to read by letting you have the contents of your ConfigMaps (or, at least, of theConfigMapsthat include bigger files) under a separate path. You can focus on adding and editing your files with any tool you like and, as long as they are sitting in your selected folder, not have to worry about adding them to your.Values.ConfigMaps.dataof your ConfigMap (e.g with Jinja templating), so you can rename your file to{something}.escape.{something}and it won't try to do that. This will also strip the.escapesection from your key when creating theConfigMap.Possible drawbacks
ConfigMaps, so they will just inherit the global onesbjw-s.common.render.configMapsin the_generate.tplfile, otherwise it won't work (more information on this below)Additional information
I wanted to keep this DRY whithout losing on the advantages that the chart already gives while creating
ConfigMapsfrom values. So I thought that, instead of differentiating between ConfigMaps declared in the values and ConfigMaps loaded from the repo, it would be better to just build theconfigMapValuesfrom the files and inject them into.Values.configMapsbeforebjw-s.common.render.configMapsgets called. This way if theConfigMapcomes from the values or from the filesystem it will be transparent to the chart.Checklist
Chart.yamlhas been bumped according to Semantic Versioning.artifacthub.io/changeschangelog annotation has been updated inChart.yaml. See Artifact Hub documentation for more info.values.yamlfile.