First pass

Next steps:
* Update other repos to use this
* Blog about it :P

.drone.yml

@@ -0,0 +1,18 @@
+kind: pipeline
+name: auto-repo-update-drone-plugin
+type: docker
+
+platform:
+  os: linux
+  arch: arm64
+
+steps:
+  - name: push-built-image
+    image: plugins/docker
+    settings:
+      registry: gitea.scubbo.org
+      repo: gitea.scubbo.org/scubbo/auto-repo-update-drone-plugin
+      tags: latest
+      username: scubbo
+      password:
+        from_secret: gitea_password

Dockerfile

@@ -0,0 +1,9 @@
+FROM alpine/git
+
+RUN apk update
+# For envsubst
+RUN apk add gettext
+
+ADD script.sh /bin
+RUN chmod +x /bin/script.sh
+ENTRYPOINT /bin/script.sh

README.md

@@ -0,0 +1,38 @@
+# TL;DR
+
+This Drone plugin makes (and pushes) an automated commit to a Git repo. Use this to create a step in a Drone pipeline that updates an IaC repo ("watched" by a CD system) to reflect a newly-available image of Application Code.
+
+# Information
+
+## Motivation
+
+The [GitOps](https://www.gitops.tech/) development style encourages:
+* Defining the infrastructural elements of an application in Source-controllable form (using an IaC tool such as [AWS CDK](https://aws.amazon.com/cdk/), [K8s manifest files](https://kubernetes.io/)/[Helm Charts](https://helm.sh/), etc.)
+* Using Continuous Deployment systems (such as [AWS CodeDeploy](https://aws.amazon.com/codedeploy/) or [ArgoCD](https://argo-cd.readthedocs.io/en/stable/)) to ensure that the deployed state of the application matches the intended state, as defined in checked-in version-controlled specification.
+
+Updates to infrastructural definition are naturally propagated out to deployed environments via the operation of the CD systems. However, updates to the application code should also result in deployments (once that application code has passed all appropriate tests), but this is not natively supported by CD systems - since Infrastructure definitions tend to define the specific App Code version that should be deployed to each stage[^1], making a deployment of a new App Code version requires an update to the Infrastructure definition as well. This plugin automates that process.
+
+## Operation
+
+This plugin assumes that the mapping of "_which Image tag should be deployed to which deployment stage_" is managed with simple files - for each stage, there is a single file which contains only the tag that should be deployed to that stage. Examples of this setup can be found in the sample repos for [App Code](https://gitea.scubbo.org/scubbo/auto-update-test-app-code) & [Infra Code](https://gitea.scubbo.org/scubbo/auto-update-test-infra-code).
+
+## Variables
+
+| Variable name    | Variable meaning                                                                                                                                                                                      | Example value                                                                    |
+|------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------|
+| BRANCH           | The branch of the Infrastructure Repo on which to make a commit                                                                                                                                       | `main`                                                                           |
+| GIT_REPO         | The (https://) address of the Infrastructure Repo                                                                                                                                                     | `https://github.com/myusername/coolrepo`                                         |
+| IMAGE_TAG        | The Image Tag to insert into a tracking file                                                                                                                                                          | `a6b6e8`                                                                         |
+| DESTINATION_FILE | The file in Infrastructure Repo that should be updated to contain `IMAGE_TAG`                                                                                                                         | `deployed_tags/prod_image_tag`                                                   |
+| AUTHOR_EMAIL     | The email that should be associated with the automated commit                                                                                                                                         | `myname@gmail.com`                                                               |
+| AUTHOR_NAME      | The name that should be associated with the automated commit                                                                                                                                          | `Adam Nonymous`                                                                  |
+| COMMIT_MESSAGE   | Commit message. Expands environment variables ([note that](https://docs.drone.io/plugins/overview/#plugin-inputs) any of these variables should have `PLUGIN_` prepended if you are referencing them) | `[Auto] Automated commit to write $PLUGIN_IMAGE_TAG to $PLUGIN_DESTINATION_FILE` |
+| ACCESS_TOKEN     | Personal Access Token providing access to the Git Repo                                                                                                                                                | <PAT>                                                                            |
+
+# FAQs
+
+## Couldn't you just do this by declaring the deployed tag as a Parameter of the Argo deployment?
+
+Honestly - that's probably a better approach. I'm still learning about CI/CD after my previous life as an Amazon SDE, and figuring out capabilities and best practices is taking a while (I've earmarked the great answers to [this SO question to read](https://devops.stackexchange.com/questions/12803/best-practices-for-app-and-infrastructure-code-repositories), but haven't gotten to it yet). Nonetheless, this was a neat opportunity to learn how to make a Drone plugin! I'd prefer to "get my hands dirty" implementing both approaches before I make a decision on which I prefer.
+
+[^1]: As I discuss [here](https://blog.scubbo.org/posts/ci-cd-cd-oh-my/), Amazon's own internal CI/CD system didn't use this pattern, instead declaring the App Code element that should be deployed to a given Compute element (Lambda/ECS/etc.), and letting the Pipeline system control determine "_the latest App Code revision that has passed all preceding tests_". Part of my intention in writing that blog post and in creating this plugin was to explore the default model of OSS CD systems - "_The deployed-version of App Code should be determined by the contents of a Git Repo rather than by the state of a Pipeline_" - and to understand its pros and cons vs. "_the Amazonian model_".

script.sh

@@ -0,0 +1,16 @@
+#!/bin/sh
+
+set -eox pipefail
+
+mkdir /working
+cd /working
+git clone -b "$PLUGIN_BRANCH" "$PLUGIN_GIT_REPO" .
+echo "$PLUGIN_IMAGE_TAG" > "$PLUGIN_DESTINATION_FILE"
+git add "$PLUGIN_DESTINATION_FILE"
+git config user.email "$PLUGIN_AUTHOR_EMAIL"
+git config user.name "$PLUGIN_AUTHOR_NAME"
+# https://stackoverflow.com/a/31926346/1040915
+git commit -m "$(echo $PLUGIN_COMMIT_MESSAGE | envsubst)"
+# https://stackoverflow.com/a/6174447/1040915
+git remote add origin-with-credentials "$(echo $PLUGIN_GIT_REPO | sed -e's,^\(.*://\).*,\1,g')""$PLUGIN_ACCESS_TOKEN@""$(echo $PLUGIN_GIT_REPO | sed -e's,^.*://\(.*\),\1,g')"
+git push origin-with-credentials "$PLUGIN_BRANCH":"$PLUGIN_BRANCH"