Skip to main content

​
Overview

Production Go Lambdas under apps/*-lambda ship through the Lambda Deploy workflow on every push to prod and through workflow_dispatch (manual Lambda Deploy run). Each deploy job builds a Linux bootstrap binary, uploads a versioned artifact to S3, and updates the function code via SSM parameters and shared actions under .github/actions/. Current workers: Concurrency groups append ${{ github.ref }} (for example refs/heads/prod). Every deploy job uses the same AWS role session name: github-actions-lambda-deploy. Infrastructure provisioning (queues, IAM, SSM parameter names) lives in the infra repository. See Activity-log SQS and Go Lambda infrastructure.

​
No path filters

Every push to prod deploys every Lambda. Do not add on.push.paths or per-job path filters. Path filters used to decide which workers to deploy. They drifted from the real Go import graph. For example, glossary-interchange imports internal/objectstore and memory-interchange imports internal/activitylog, but neither filter listed those packages. A change there would reach prod without redeploying the affected Lambda.

​
Concurrency

Deploy jobs use per-lambda concurrency groups, for example lambda-deploy-glossary-interchange-refs/heads/prod, with cancel-in-progress: true. A newer push cancels only the same worker’s in-progress deploy, and the newer run redeploys that worker. Push deploys also run ensure-deploy-main-tip after checkout. It skips the job when prod has moved past the run’s commit, so an older run never overwrites a newer deploy. workflow_dispatch runs skip the check.

​
Rules when changing the workflow

  • Do add a dedicated concurrency block on each deploy job when you add a new worker.
  • Do not make deploy jobs conditional on changed paths.
Decision record: Lambda deploy job-level concurrency.

​
Adding a new worker

Use the create-sqs-lambda-worker skill. At minimum in lambda-deploy.yml:
  1. Add a deploy job with if: github.ref == 'refs/heads/prod'.
  2. Add job-level concurrency with a unique group name (lambda-deploy-<worker>-${{ github.ref }}).
  3. Call ensure-deploy-main-tip after checkout.
  4. Set role-session-name: github-actions-lambda-deploy on the new job’s configure-aws-credentials step (same value as every other deploy job on prod).

​
Do not change when launching a new Lambda

When you add a worker, extend the workflow. Do not refactor existing deploy jobs or shared CI behavior.
  • Do not use per-worker role-session-name values. All Lambda deploy jobs on prod use github-actions-lambda-deploy only.
  • Do not change role-session-name on existing deploy jobs when adding a worker.
  • Do not add path filters.
  • Do not remove ensure-deploy-main-tip or per-job concurrency from existing workers.
  • Do not change existing concurrency group names for workers already in production.
Copy an existing deploy job as a template, then limit edits to the new worker’s paths, tests, build targets, SSM parameters, artifact key, and concurrency group. Root AGENTS.md summarizes the same rules for automation.

​
Operations

Open the completed deploy job on prod. The Summarize step writes function name, S3 URI, version id, and commit SHA to the job summary.