This repo, in conjunction with the [App Code repo](https://gitea.scubbo.org/scubbo/auto-update-test-app-code), 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](https://gitea.scubbo.org/scubbo/auto-update-test-app-code/commit/65866ea3b60906d60c4c7aa22b51333cb906c839)), 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](https://helm.sh/docs/chart_template_guide/accessing_files) 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.