This repo (along with the sibling repo which defines app code) demonstrates how to use the Auto Update Drone Plugin to automate the process of updating the deployed version of Application Code via CI/CD.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
Jack Jackson a25a8b16a5
[Auto] Update helm/deployed-images/prod to 20e3f69613
1 month ago
helm [Auto] Update helm/deployed-images/prod to 20e3f69613 1 month ago
README.md First commit 1 month ago

README.md

This repo, in conjunction with the App Code repo, demonstrates how to use the Auto-Update Drone Plugin to trigger App deployments in a CI/CD pipeline which uses GitOps to define the App Versions in Git.

Demonstration

While in the App Code repo, at commit 65866e (link), and having already carried out a "first-pass" sync in my CD application (ArgoCD) to get components deployed:

# Make the deployed pod "call itself" - saves us from the hassle of setting up a Service
$ kubectl exec -it -n auto-update $(kubectl -n auto-update get pods -o=jsonpath='{.items[*].metadata.name}') -- curl localhost:8000
Hello world!%
# OK, good - as expected, the Application initially responds with "Hello world!". Now let's make a change and demonstrate that it's deployed.
$ git reset --hard cffc43
HEAD is now at cffc437 Expand project scope
$ git status
On branch main
Your branch is ahead of 'origin/main' by 1 commit.

nothing to commit, working tree clean
$ git push
[...]
To https://gitea.scubbo.org/scubbo/auto-update-test-app-code.git
   65866ea..cffc437  main -> main
#
# Now observe:
# * the Drone pipeline results in a commit to the infra package...
# * ...which is visible in Gitea
# * Once the Argo application is synced, new Kubernetes resources are created to match the new Infrastructure definition
#
$ kubectl exec -it -n auto-update $(kubectl -n auto-update get pods -o=jsonpath='{.items[*].metadata.name}') -- curl localhost:8000
Hello universe!

Points to note

  • helm/templates/_helpers.tpl contains the fullImageName definition, which in turn depends on imageTag, which uses Files access to read the contents of helm/deployed-images/<targetEnv>
  • The value targetEnv must be set in the setup for the specific CD application which will "watch" this repo for updates.