Problem
The agency Helm chart's configFiles mechanism (deployments/helm/agency) only supports inline content defined directly in Helm values — each entry in configFiles is rendered verbatim into a chart-managed ConfigMap. Teams that manage this kind of config (JSON Schemas, data-scope rules — see backend/config/<agency>/) via GitOps/Kustomize outside of Helm, or who already maintain a ConfigMap/Secret through another pipeline, have no way to point the chart at that existing resource instead of duplicating the content into their Helm values file.
Proposed Solution
Add an existingConfigMap value (the name of a pre-existing ConfigMap) as an alternative to configFiles in the agency chart. When set, templates/deployment.yaml would mount that ConfigMap the same way (configFilesMountPath, read-only) instead of the chart-rendered one, and templates/configmap.yaml would skip creating its own. The two options should be mutually exclusive, with configFiles remaining the default/simple path for values-only deployments.
Alternatives
Keep configFiles as the only supported mechanism, and require deployers who manage config outside Helm to either inline the content into their values file anyway, or fall back to the chart's generic volumes/volumeMounts passthrough and hand-write the volume stanza referencing their own ConfigMap by name.
Problem
The
agencyHelm chart'sconfigFilesmechanism (deployments/helm/agency) only supports inline content defined directly in Helm values — each entry inconfigFilesis rendered verbatim into a chart-managed ConfigMap. Teams that manage this kind of config (JSON Schemas, data-scope rules — seebackend/config/<agency>/) via GitOps/Kustomize outside of Helm, or who already maintain a ConfigMap/Secret through another pipeline, have no way to point the chart at that existing resource instead of duplicating the content into their Helm values file.Proposed Solution
Add an
existingConfigMapvalue (the name of a pre-existing ConfigMap) as an alternative toconfigFilesin theagencychart. When set,templates/deployment.yamlwould mount that ConfigMap the same way (configFilesMountPath, read-only) instead of the chart-rendered one, andtemplates/configmap.yamlwould skip creating its own. The two options should be mutually exclusive, withconfigFilesremaining the default/simple path for values-only deployments.Alternatives
Keep
configFilesas the only supported mechanism, and require deployers who manage config outside Helm to either inline the content into their values file anyway, or fall back to the chart's genericvolumes/volumeMountspassthrough and hand-write the volume stanza referencing their own ConfigMap by name.