is it possible that argocd manage multiple git branches?

[BlueEye0609]

we have the below situation.
gitlab pipeline to build images and helm charts.
in github repo, we define the argocd managed application. The configuration is like below

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name:workload
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  destination:
    name: in-cluster
    namespace: argocd
  source:
    repoURL: 'https://github.com/dev-cluster.git'
    targetRevision: HEAD
    path: argocd/workload
  syncPolicy:
    automated:
      selfHeal: true
      prune: true

and under path argocd/workload we define again with the application's config

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: istio
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  destination:
    name: in-cluster
    namespace: default
  source:
    repoURL: 'https://github.com/dev-cluster.git'
    targetRevision: HEAD
    path: argocd/workload/istio
  syncPolicy:
    automated:
      selfHeal: true
      prune: true

and then the HEAD targetRevision will synced by argocd.

However in this case, if we want to test something like new images/new helm charts. we need to always modify the main branch's targetRevision. It is not convenient for developers to test app in k8s.
Do we have a way e.g. argocd can manage multiple git branches, and based on the settings in the git branch, it can deploy another application in the cluster?
or does someone have some other good solutions for it?
many thanks

[RomanBats]

I usually use helm charts for such configurations.
What could be done in your situation is:

Under "argocd/workload" you would create a new Helm chart:

argocd/workload/
  Chart.yaml          # A YAML file containing information about the chart
  values.yaml         # The default configuration values for this chart
  templates/          # A directory of templates that, when combined with values,
                      # will generate valid Kubernetes manifest files.

In the "templates/" folder of the Helm chart you would put your ArgoCD Application (Istio in your example)

argocd/workload/templates/
  istio.application.yaml
  # other applications

In values.yaml you would define your parameter:

targetRevision: 'HEAD' # default value would be HEAD

Your Istio application (istio.application.yaml) would use that new parameter:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: istio
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  destination:
    name: in-cluster
    namespace: default
  source:
    repoURL: 'https://github.com/dev-cluster.git'
    targetRevision: {{ .Values.targetRevision }} # <------------- new parameter is used here
    path: argocd/workload/istio
  syncPolicy:
    automated:
      selfHeal: true
      prune: true

And finally, your root application "workload" would be installing not just the folder but your new Helm chart:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name:workload
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  destination:
    name: in-cluster
    namespace: argocd
  source:
    repoURL: 'https://github.com/dev-cluster.git'
    targetRevision: HEAD
    path: argocd/workload
    helm:
      valueFiles:
        - values.yaml
      values: |
        targetRevision: 'HEAD'
  syncPolicy:
    automated:
      selfHeal: true
      prune: true

So in the result, by default, you would be installing from HEAD, but if a developer needs to try something, he/she would be able to use ArgoCD UI to overwrite "targetRevision" value to anything else.

[BlueEye0609]

in this case, can multiple developers overwrite "targetRevision" with different branches and argocd can handle multiple applications without any errors?

[RomanBats]

With the configuration I provided - definitely no. It will install your application once for the targetRevision you have specified.

But, you can really extend this approach to support multiple versions of your application, in this case, you would have:
targetVersions:

- HEAD
- branchOne
- branchTwo

And you would iterate through this list and create istio application for each item (with a unique name).

[jheck88]

It would be really nice if I could just setup a regex for branches and deploy an application per branch if it matched the regex. Same with updating to latest tagged branch.

[crenshaw-dev]

@jheck88 that sounds like what an ApplicationSet SCM generator does when allBranches is enabled.

[jheck88]

@crenshaw-dev that's like 90% it. Wondering if it will only accept a group or if i can draw it down to a project level to scrape branches.