Skip to content

v0.47.3 — Cut the Terraform CI job back to fmt and validate

Cut the Terraform CI job back to fmt + validate. Its Plan / Apply / Destroy steps could never have deployed anything, and saying otherwise cost real time: v0.47.1 was believed shipped for as long as it took to notice prod had not moved.

  • No state. The S3 backend in infra/main.tf is commented out and terraform.tfstate is gitignored, so a CI run starts from empty state. An apply would try to create the infrastructure from scratch, not update it.
  • No variables. The steps passed -var-file=environments/<env>.tfvars, but infra/environments/ does not exist in the repo. The real file is infra/prod.tfvars, gitignored.
  • Nothing to apply anyway. ci.yml's "Update ECS task definition and service" step owns the running task definition: it reads the live one, swaps only the image, and re-registers it. Every other field — the whole environment block infra/ecs.tf describes — is carried forward from what is already deployed. Terraform never gets a say.
  • Dropped the AWS credentials step too. A job that cannot deploy should not be handed deploy keys.
  • terraform init -backend=false, so linting installs provider schemas without creating a state file it has no business holding.

Terraform remains a description of infrastructure that is applied by hand, from a workstation with local state and local tfvars. Making it deploy for real needs three things first: a remote backend, a committed or CI-provisioned var-file, and a decision about whether Terraform or ci.yml owns the ECS task definition — currently both think they do.

Verified against a clean checkout of infra/ with no AWS credentials and no state: all three steps exit 0.