3

The part that confuses me about is the recommendation to separate source-code from manifests, e.g. This is what has to say about it:

The use of a different Git repository to hold your kubernetes manifests (separate from your application source code), is highly recommended. See best practices for further rationale.

In a typical project, I would use to setup a test environment and then on_stop action to delete the environment for each PR. However, if I separate manifests from the source code, it is not clear what is supposed to be watching.

For the sake of example lets assume that we have two repositories:

  • foo hosts the app code
  • bar hosts manifests of different apps

Suppose:

  1. I've created a new branch feature-001 in foo branch.
  2. Every time we add a commit to feature-001 it creates a new image (foo:$COMMIT_SHA).

How would I create a controlled app that watches this branch for changes?

I can of course create the app using CLI:

argocd app create "foo-$COMMIT_SHA" --repo https://github.com/gajus/bar.git --path bar -p image=foo:$COMMIT_SHA

but how would ArgoCD know to track this feature-001 branch for changes?, i.e. How do I tell to deploy a new version of the app when a new Docker image is published from this branch?

Gajus
  • 69,002
  • 70
  • 275
  • 438

2 Answers2

4

How would I create a argocd controlled app that watches this branch for changes?

I am not sure why you are dismissing the CLI option. The CLI can create an application including pointing to a git revision which (can be a branch).

For example:

argocd app create "foo-$COMMIT_NAME"
  --repo https://github.com/gajus/bar.git
  --path bar
  --revision $BRANCH_NAME
  --parameter image=foo:$COMMIT_SHA
  --sync-policy automated

Note the automated sync-policy being set here. That will meant that any updates to the revision will update the branch.

How do I tell argocd to deploy a new version of the app when a new Docker image is published from this branch

The above answer explains how the ArgoCD Application can track git changes, but this question hints at the issue of updating the tag within the deployment/replicaset manifest. This is highly dependent on how you do this for your main branch. Some people will have that hard coded, others commit the $COMMIT_SHA from repo foo to repo bar, and others use a templating language and inject variables.

Based on your concern I am going to assume you follow the commit from repo foo to repo bar approach. If this is the case, I would suggest adding the flag --upsert into the CLI command and just running the same CLI command each time in your branch pipeline.

NOTE: Added bonus option here is to add an additional flag for something like --label branch=${BRANCH_NAME}. This can then be used to find/cleanup any branch deploys on a regular basis.

abldn
  • 81
  • 3
0

So you have

  • git:foo hosts the app code
  • git:bar hosts manifests of different apps
  1. ArgoCD your CD only watches git:bar
  2. Your CI build system watches git:foo for changes e.g. branches, commits, pr's
  3. As part of CI build it creates new container and uploads to container registry with my favorite tag "YYYYMMDD-BuildId-ShortGitHash"
  4. The magic ✨, the CI then check's out git:bar, and updates the relevant config with the new container tag, and commits the change, this will trigger ArgoCD.
  5. ArgoCD detects change in git:bar and makes necessary changes to k8s to get new container deployed.
Pieter
  • 1,916
  • 17
  • 17