You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As far as I understand the network-operator repo has two deployment pipelines - a helm chart and a kustomize flow. This can cause issues where changes need to be made on both in parallel and kept in sync.
This would allow the helm charts to be the source of truth for creation of the manifests with a layer of kustomize patches for workflows where needed. The end result should be that much of the config folder could be regenerated on the fly, leaving only specific configurations, e.g. default, dev, actually having meaningful changes.
This should be enforced by adding a CI check to ensure the kustomize bases do not go out of sync with what is generated from the helm charts.
The text was updated successfully, but these errors were encountered:
As far as I understand the network-operator repo has two deployment pipelines - a helm chart and a kustomize flow. This can cause issues where changes need to be made on both in parallel and kept in sync.
In order to convert this to a single flow we could generate the kustomize bases from the helm charts. This should be possible with https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md but requires some config to get it right.
This would allow the helm charts to be the source of truth for creation of the manifests with a layer of
kustomize
patches for workflows where needed. The end result should be that much of theconfig
folder could be regenerated on the fly, leaving only specific configurations, e.g.default
,dev
, actually having meaningful changes.This should be enforced by adding a CI check to ensure the kustomize bases do not go out of sync with what is generated from the helm charts.
The text was updated successfully, but these errors were encountered: