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.