A Drone plugin to automatically update an Infrastructure Repo in response to an updated revision of Application Code. (More info in this blog post - https://blog.scubbo.org/posts/ci-cd-cd-oh-my/)
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 d5df1316f8
continuous-integration/drone/push Build is passing Details
Do nothing if there is nothing to do!
2 weeks ago
.drone.yml Add TODO note about pushing to Docker Hub 1 month ago
Dockerfile First pass 1 month ago
README.md Set default values 1 month ago
script.sh Do nothing if there is nothing to do! 2 weeks ago

README.md

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 development style encourages:

  • Defining the infrastructural elements of an application in Source-controllable form (using an IaC tool such as AWS CDK, K8s manifest files/Helm Charts, etc.)
  • Using Continuous Deployment systems (such as AWS CodeDeploy or ArgoCD) 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 stage1, 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 & Infra Code.

Variables

Variable name Required? Variable meaning Example value (default value for optional variables)
BRANCH No The branch of the Infrastructure Repo on which to make a commit main
AUTHOR_EMAIL No The email that should be associated with the automated commit auto-update-bot@example.com
AUTHOR_NAME No The name that should be associated with the automated commit Auto Update Bot
COMMIT_MESSAGE No Commit message. Expands environment variables (note that any of these variables should have PLUGIN_ prepended if you are referencing them) [Auto] Update $DESTINATION_FILE to $IMAGE_TAG
GIT_REPO Yes The (https://) address of the Infrastructure Repo https://github.com/myusername/coolrepo
IMAGE_TAG Yes The Image Tag to insert into a tracking file a6b6e8
DESTINATION_FILE Yes The file in Infrastructure Repo that should be updated to contain IMAGE_TAG deployed_tags/prod_image_tag
ACCESS_TOKEN Yes Personal Access Token providing access to the Git Repo

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, 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, 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". ↩︎