#argocd (2023-11)

My org has app config files that just use:

name: "appname"
values: |
  all the values...

So far I’m not spotting why that decision was a better decision than keeping to the overall yaml structure that would more closely align with every other file in the process.

@RickA I’m not sure that I got your question right, but let me give you some details on how we use argocd.

1. We have argocd-deploy repository on GitHub. This is the source of truth that ArgoCD looks into.
2. Each application repository (ex: https://github.com/cloudposse/example-app-on-eks-with-argocd) has helmfile (https://github.com/cloudposse/example-app-on-eks-with-argocd/blob/master/deploy/releases/app.yaml) in it. That helmfile declares all helm releases, values, and environment-dependent application configs.
3. GitHub action https://github.com/cloudposse/github-action-deploy-argocd renders k8s manifests with helmfile and commits them into argocd-deploy repo.

This architecture gives developers control over how to define helm charts and values.

In the link I provided there’s a values.yaml structured like yaml:

source:
  helm:
    valuesObject:
      ingress:
        enabled: true

And then one that ends up being mostly strings:

source:
  helm:
    values: |
      ingress:
        enabled: true

So everything after values: | is just a string.

I’m trying to determine what decision points would influence our choice there. So this is strictly an ArgoCD question and not Cloudposse related. We’re “native” if you will with ArgoCD (which seems weird when they’re not native Helm ).