argo-cd how to test configuration in a "development" cluster before going live

Question

I have a single argocd repository which contains all the configuration for the Kubernetes cluster. Now I want to work with PRs and only want to merge things which were tested on our continuous integration system before they can be merged. To do so, my idea was to have another cluster which I then deploy the branch to. Sadly, argocd defines the revision and targetRevision inside its yaml files – therefore, this is “hard-coded” inside git.

What is the best way to switch the revision, so I can “apply” any feature branch and still link it to a cluster?

Target

GIT - Branch master    -> prod-Cluster
    - Branch dev       -> dev-Cluster
    - Branch feature.. -> feature-Cluster using kind

ArgoCD Config

Application (root) -> ApplicationSet (app-of-appset) -> apps/* directory containing kustomization files

Example argo config for application set

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: cluster-addons
spec:
  generators:
  - git:
      repoURL: https://github.com/argoproj-labs/applicationset.git
      revision: HEAD <--------- Thats what I want to adjust for testing
      directories:
      - path: examples/git-generator-directory/cluster-addons/*
  template:
    metadata:
      name: '{{path.basename}}'
    spec:
      project: default
      source:
        repoURL: https://github.com/argoproj-labs/applicationset.git
        targetRevision: HEAD <--------- Thats what I want to adjust for testing
        path: '{{path}}'
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{path.basename}}'

Answer 1

I think the only way is to deploy different apps for each branch within the same repo. Look at the following info from ArgoCD documentation:

You can also store parameter overrides in an application specific file, if you are sourcing multiple applications from a single path in your repository.

The application specific file must be named .argocd-source-<appname>.yaml, where is the name of the application the overrides are valid for.

If there exists an non-application specific .argocd-source.yaml, parameters included in that file will be merged first, and then the application specific parameters are merged, which can also contain overrides to the parameters stored in the non-application specific file.

Or you can try to patch the application:

argocd app patch APPNAME --patch '[{"op": "replace", "path": "/spec/template/spec/source/targetRevision", "value": "HEAD"}]'

and then argocd app sync APPNAME

However everything gets difficult when it's hardcoded.