Jenkins X 3 and Argo CD

Jenkins X 3 and Argo CD

There have been a number of requests from the Jenkins X community to use Argo CD for the last mile deployment phase of their continuous delivery pipelines. This blog explains some of the advantages of using Jenkins X and Argo CD all together.

What’s included?

  • Jenkins X for Cloud Infrastructure using Terraform, core installation management with GitOps, external secret management, ingress controller, quickstarts, automated CI + CD pipelines, ChatOps
  • Tekton for pipeline orchestration
  • Argo CD for end users application deployments (not the main installation) Argo CD provides a declarative GitOps approach to deploying Kubernetes based applications. There is a GUI which helps construct the deployment definition (in the form of an Application custom resource) which offers a number of configuration options, as well and providing insight into your clusters applications.

You might be wondering why you would want to use BOTH Jenkins X and Argo CD together. Jenkins X aims to embrace OSS, where possible providing a nice UX to integrate with other projects and help provide better solutions for building, developing and running software on Kubernetes. Jenkins X indeed does have a git operator that applies Kubernetes YAML from a Git repository but there are some differences:

  • Jenkins X uses GitOps principles for the entire installation, i.e. the starting point is a Git repository which is used to provision a cluster and manage (automatic if users wish) upgrades whereas today Argo CD uses a manual kubectl apply to manage the Argo installation itself.

  • External Secrets integration for Vault, Google Secrets manager etc is something that Jenkins X provides out of the box. When Kubernetes based applications require a secret we prefer the source is stored in a secrets manager and the value synchronised automatically into the cluster enabling easier secret rotation, avoiding local secrets on machines and an easier UX for working with secrets. When adding an Application via Argo CD users can leverage the Jenkins X approach to working with secrets and rely on Argo to manage the deployments. If users prefer to work with SOPS that is totally fine too and will work in the same way as they are used to.

  • If you do not wish to expose direct access for the Kubernetes cluster to developers then using a combination of Jenkins X UI for accessing logs and Argo CD for managing application deployments may be enough.

  • Using the Jenkins X approach to promoting via automated pull requests via pipelines to add new helm charts and update chart release version numbers.

  • In a Jenkins X multi cluster setup you can choose to use jx-git-operator or Argo CD in the remote cluster to syncronise promoted applications into the staging or production clusters. This way you get all the benefits of the integrated Jenkins X experience to manage the build infrastructure and provide the developer experience like preview environments and chatops etc.

This is done by creating a new Git repository that will contain a number of Argo CD Application Kubernetes resources. This also means we handle disaster recovery scenarios and are able to recover the Jenkins X installation which includes Argo CD plus any applications managed by Argo CD itself.

There may be a couple of models to try but here we are going to describe an approach we have validated when using Jenkins X to manage the core Kubernetes installation, using Tekton for Continuous Integration, Jenkins X for application promotion and Argo CD for deployments.

Install Argo CD with Jenkins X

  • Prerequisite is a working Jenkins X 3 installation
  1. Add a Argo CD helmefile to your Jenkins X cluster git repository:
mkdir -p helmfiles/argocd

Create a new file


namespace: argocd
- chart: argocd/argo-cd
  name: argocd
- chart: ../../charts/argo-applications
  name: argo-applications

Edit the root ./helmfile.yaml and add a new path reference to the helmfile above

- path: helmfiles/argocd/helmfile.yaml

Jenkins X will resolve default helm values from the Jenkins X version stream.

  1. Create a new git repository to contain the Argo CD Application Kubernetes resources, this means we can use Jenkins X pipelines to promote users applications via GitOps.

  2. Back in your clusters Git repository create a new folder:

mkdir -p charts/argo-applications

create a file in the new folder and replace the repoURL: with the Git URL from step 2 above.


kind: Application
  name: staging
  namespace: argocd
    name: ''
    namespace: argocd
    server: 'https://kubernetes.default.svc'
    path: .
    targetRevision: HEAD
      recurse: true
  project: default
      prune: true
      selfHeal: true
      - Replace=true
      - CreateNamespace=true
  1. commit your changes and push
git add helmfiles/argocd/helmfile.yaml
git add charts/argo/applications.yaml
git commit -m 'feat: enable Argo CD'
git push

If you are on a fork then PR your changes

  1. Follow Jenkins X admin logs to ensure Argo CD is installed
jx admin logs
  1. Get the Argo CD UI password using something like ksd or base64 -D to decode the value:
kubectl get secret argocd-initial-admin-secret -n argocd -oyaml | ksd
  1. Get the Argo CD UI hostname and login using the admin username + passowrd from step 6 above (you may need to accept insecure TLS browser prompt if not using production TLS)
kubectl get ing argocd-server -n argocd
  1. Create a new quickstart or update an existing Jenkins X applications ./lighthouse/jenkins-x/release.yaml pipeline, replaceing the Tekton promote-jx-promote step to use argo instead:
- image: uses:jenkins-x/jx3-pipeline-catalog/tasks/updatebot/release.yaml@versionStream
  name: promote-release
  script: |
    #!/usr/bin/env sh
    source .jx/
    jx updatebot argo promote --target-git-url$REPLACE_WITH_GIT_OWNER/$REPLACE_WITH_GIT_REPO    

Now merge a change to your application or manually trigger a release pipeline jx pipeline start to get a new release and promote using Argo CD. Once the release pipeline finished for your application you should see a new application.yaml resource in your uber application Git repository we created in step 2 above. Once this change is merged to the main branch Argo detects the new chart / version and applies it to the cluster. You will be able to track the status and health of the deployment via the GUI that you logged in with step 7 above.


I really did like the experience of Argo CD, there’s some overlaps with Jenkins X across the wider projects however I think there’s enough of a differentiation for both to complement each other. What I loved was that both projects as well as others like flux promote the use of GitOps. Anyways, congratulations to the Argo project and I hope users from both communities find this blog useful and / or interesting.