Terraform – A CI/CD Pipeline in GitHub Actions

# ⚠️ Do not do this.
- uses: aws-actions/configure-aws-credentials@v4
  with:
    aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
    aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

resource "aws_iam_openid_connect_provider" "github" {
  url = "https://token.actions.githubusercontent.com"

  client_id_list = ["sts.amazonaws.com"]

  # ⚠️ NO thumbprint_list, deliberately.
  #
  # Nearly every OIDC tutorial you will find pastes a 40-character CA thumbprint
  # here, and that advice is out of date twice over. AWS no longer verifies
  # thumbprints for well-known IdPs including GitHub's, and the argument is
  # OPTIONAL on AWS provider 6.x — `terraform validate` accepts this resource
  # without it.
  #
  # The thumbprints in those tutorials are also frequently the OLD ones, from
  # before GitHub rotated its certificate authority. Copying a stale one gives
  # you a resource that looks configured and pins nothing.
}

data "aws_iam_policy_document" "github_assume" {
  statement {
    actions = ["sts:AssumeRoleWithWebIdentity"]

    principals {
      type        = "Federated"
      identifiers = [aws_iam_openid_connect_provider.github.arn]
    }

    condition {
      test     = "StringEquals"
      variable = "token.actions.githubusercontent.com:aud"
      values   = ["sts.amazonaws.com"]
    }

    # ⚠️ THE LINE THAT MAKES THIS SAFE.
    #
    # Without a `sub` condition, ANY GitHub Actions workflow in ANY repository
    # on GitHub can assume this role. Not a theoretical risk — it is the single
    # most common OIDC misconfiguration.
    #
    # StringLike, not StringEquals, because of the wildcard. Scope it as
    # narrowly as you can: a specific repo, and specific refs.
    condition {
      test     = "StringLike"
      variable = "token.actions.githubusercontent.com:sub"
      values = [
        "repo:folaulau/lovemesomecoding_demo_project:ref:refs/heads/main",
        "repo:folaulau/lovemesomecoding_demo_project:pull_request",
      ]
    }
  }
}

resource "aws_iam_role" "github_actions" {
  name               = "pizza-tf-github-actions"
  assume_role_policy = data.aws_iam_policy_document.github_assume.json
}

resource "aws_iam_role_policy" "state_access" {
  name = "terraform-state"
  role = aws_iam_role.github_actions.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = ["s3:ListBucket"]
        Resource = "arn:aws:s3:::my-terraform-state-329580012644"
      },
      {
        Effect = "Allow"
        # DeleteObject is for releasing the .tflock, not for deleting state.
        Action   = ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"]
        Resource = "arn:aws:s3:::my-terraform-state-329580012644/pizza/*"
      },
    ]
  })
}

name: terraform

on:
  pull_request:
    paths: ['infra/**']
  push:
    branches: [main]
    paths: ['infra/**']

# ⚠️ Two applies at once fight over the state lock, and the loser fails after
# doing part of its work. This queues them instead.
#
# cancel-in-progress is FALSE deliberately: cancelling an apply half way
# through leaves infrastructure created and state not yet written.
concurrency:
  group: terraform-${{ github.ref }}
  cancel-in-progress: false

permissions:
  contents: read
  id-token: write        # <- REQUIRED for OIDC. without it, no token is minted.
  pull-requests: write   # <- to post the plan as a comment

env:
  TF_VERSION: '1.15.9'
  AWS_REGION: us-west-2
  ROLE: arn:aws:iam::329580012644:role/pizza-tf-github-actions

jobs:
  plan:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: infra
    steps:
      - uses: actions/checkout@v4

      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ env.ROLE }}
          aws-region: ${{ env.AWS_REGION }}

      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: ${{ env.TF_VERSION }}

      # Formatting and validation first: they need no AWS access and they fail
      # in seconds, so a badly formatted PR does not wait on a plan.
      - run: terraform fmt -check -recursive
      - run: terraform init -input=false
      - run: terraform validate

      - name: Plan
        id: plan
        run: terraform plan -input=false -no-color -out=tfplan
        continue-on-error: true

      - name: Comment the plan
        uses: actions/github-script@v7
        env:
          PLAN: ${{ steps.plan.outputs.stdout }}
        with:
          script: |
            const body = `#### Terraform plan \`${{ steps.plan.outcome }}\`
            <details><summary>Show plan</summary>

            \`\`\`terraform
            ${process.env.PLAN}
            \`\`\`

            </details>`;
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: body.slice(0, 65000),
            })

      # continue-on-error above let the comment post even for a failed plan.
      # This makes the job red anyway, so the failure cannot be merged past.
      - if: steps.plan.outcome == 'failure'
        run: exit 1

  apply:
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest
    # A GitHub environment can require a human approval before the job starts.
    # For production, turn that on — it is the last gate before a real change.
    environment: production
    defaults:
      run:
        working-directory: infra
    steps:
      - uses: actions/checkout@v4

      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ env.ROLE }}
          aws-region: ${{ env.AWS_REGION }}

      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: ${{ env.TF_VERSION }}

      - run: terraform init -input=false

      # ⚠️ -auto-approve, and this is the one place it is correct: the plan was
      # reviewed on the pull request and a human approved the environment. There
      # is no terminal here to type "yes" into.
      - run: terraform apply -input=false -auto-approve

name: deploy-api

on:
  push:
    branches: [main]
    paths: ['pizza/pizza-springboot-backend/**']

permissions:
  contents: read
  id-token: write

jobs:
  test:
    # Tests in their OWN job, before any image is built. The Dockerfile uses
    # -DskipTests deliberately: a build that also tests makes every image build
    # pay for the suite and reports a test failure as a build failure.
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: '21'
          distribution: temurin
          cache: maven
      - run: ./mvnw -B test
        working-directory: pizza/pizza-springboot-backend

  build-and-deploy:
    needs: test
    # ⚠️ An ARM runner, because the task definition says ARM64 and the two MUST
    # match. Building amd64 here and running ARM64 there gives you
    # `exec format error` at runtime with nothing failing at build time.
    # These runners are free for public repositories.
    runs-on: ubuntu-24.04-arm
    steps:
      - uses: actions/checkout@v4

      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::329580012644:role/pizza-tf-github-actions
          aws-region: us-west-2

      - uses: aws-actions/amazon-ecr-login@v2
        id: ecr

      - uses: docker/setup-buildx-action@v3

      - uses: docker/build-push-action@v6
        with:
          context: pizza/pizza-springboot-backend
          platforms: linux/arm64
          push: true
          # ⚠️ Tagged with the commit SHA, never :latest. The ECR repository is
          # IMMUTABLE, so :latest would fail the push anyway — but the real
          # reason is that ":latest is running" is not an answer to "what is
          # running?", and it makes a rollback impossible to name.
          tags: ${{ steps.ecr.outputs.registry }}/pizza-tf:${{ github.sha }}
          # A CI runner starts with an empty layer cache. Without this every
          # build re-downloads the whole Maven dependency tree.
          cache-from: type=gha
          cache-to: type=gha,mode=max

      - name: Roll the service onto the new image
        run: |
          aws ecs update-service \
            --cluster pizza-tf --service pizza-tf \
            --force-new-deployment

          # ⚠️ Without this the job goes green the moment the API call returns,
          # which is BEFORE the new task is healthy. A deploy that fails its
          # health check would report success.
          aws ecs wait services-stable \
            --cluster pizza-tf --services pizza-tf

terraform apply -var "image_tag=${{ github.sha }}"

      - uses: aws-actions/amazon-ecs-render-task-definition@v1
        id: taskdef
        with:
          task-definition: taskdef.json
          container-name: api
          image: ${{ steps.ecr.outputs.registry }}/pizza-tf:${{ github.sha }}

      - uses: aws-actions/amazon-ecs-deploy-task-definition@v2
        with:
          task-definition: ${{ steps.taskdef.outputs.task-definition }}
          service: pizza-tf
          cluster: pizza-tf
          wait-for-service-stability: true

terraform fmt -check -recursive    # formatting, seconds, no credentials
terraform validate                 # schema, no credentials
tflint                             # provider-aware lint: bad instance types, etc.
tfsec / checkov                     # security: public buckets, open groups, no encryption