Automated patching for arclight - trigger existing codebuild project

[barbarahui]

As of 8/25/2026 This has been deployed to stage but not production.

The infrastructure code in this PR adds an eventbridge scheduler, which triggers a lambda function weekly. This lambda function figures out the git hash of the code that is currently deployed to ECS, and then triggers a build/deploy using that source version.

The prd codebuild is updated to add the build date/time to the image tag, so that we know when the image was last patched. (The stage images will continue to simply use the latest tag, but we can easily change that if it would seem helpful to add the date?).

(A much more complex patching approach using codepipeline is in this PR: infrastructure-arclight-auto-patching)

Decision not to use CodePipeLine for patching

Background:

• we want to patch our app containers weekly
• patching: rebuild image and redeploy to ECS
• we assume that rebuilding the image will include OS level patching
• we want to make sure we use the code version that's currently deployed to ECS

new functionality that needed building out:

• a cron job: aws eventbridge
• a lambda function to determine the git hash for the currently deployed code and trigger a new build/deploy using that code version
• add date/time to docker image tag so we can see when image was last built, i.e. patched
• (we currently tag our prod images with the version)

CodeBuild vs CodePipeline

• we currently use CodeBuild to source, build, and deploy our application code
• In CodePipeline, by contrast, this is meant to be broken out into various stages: Source, Build, Deploy, etc
• Amy and I had felt some dissonance around using CodeBuild to do all of these things, i.e. should a build project also deploy?
• Also, IAS and others have used eventbridge + codepipeline to manage their patching jobs
• So, I set out basically assuming that codepipeline was the way to go

Why I ended up backing out of the codepipeline approach

• parsing out what is essentially a bash script into various stages was no small feat
• I had to:
  • modify our codebuild template to allow for codepipeline as a source option
  • codepipeline doesn't natively support github releases as a build trigger, only git tags, so that had to be figured out
  • had to figure out passing the necessary information between stages in codepipeline
  • our build steps are too complex to use codepipeline's pre-baked ECS deploy feature
• In the end, the complexity of parsing out a neat codebuild project into a multi-stage codepipeline consisting of multiple lambda functions just didn't make sense, when codebuild is working just fine for us.
• Maybe if we insert testing or have a need for a more complex branched pipeline, it will make sense to use it in the future.
• If you're starting to write infrastructure code from scratch and can use codepipeline's built-in features, it could make sense to use pipeline from the get-go