common practice to manage missing dependencies in helm chart ci

2/24/2022

Imagin one product chart contains two sub charts, app and config, app depends on config, for example, a deployment depend on configmap mounting volume. The real senario could be multiple app charts sharing same config, but only one here for simplicity.

Goal

  1. product chart design need support coexistance of multiple releases in same namespace, isolated with each other.
  2. Need app ci success alone, here success only means the app chart can be successfully deployed to k8s, no need function tests.

    Problem

    To accomplish goal 1, I think the natual way is template prefixing config name with {{ .Release.Name }}. But when in ci, the dependency {{ .Release.Name }}-config is missing, so apparently ci would fail. So violates goal 2.

    Possible solutions

  3. Deploy config before(or during) app ci, but this causes extra effort and resource usage to ci.

  4. Add if else logic in app chart to determine whether currently is in ci, if true, not render those config parts. but introduce a chart logic only for ci seems foolish.

    So is this common problem in k8s helm charts development, and what's the best practice? Is there any existing k8s mechanism to easily mock a object during ci deployment?

-- Lei Yang
continuous-integration
dependency-management
helm3
kubernetes
kubernetes-helm

0 Answers