.github/workflows/ami-build.yml (4)

20-20: Consider making STAGE a workflow input parameter.

The current approach requires editing the workflow file to change stages. This is error-prone and doesn't align with best practices for environment management.

Consider moving STAGE to a workflow input parameter:

  workflow_dispatch:
    inputs:
+     stage:
+       description: "Deployment stage (prod or dev)"
+       type: choice
+       options:
+         - prod
+         - dev
+       default: prod
      force_build:
        description: "Force AMI build even if not a release"
        type: boolean
        default: false

Then reference it in the env section:

 env:
   AWS_REGION: us-east-2
-  STAGE: prod  # Change to 'dev' for development AMIs
+  STAGE: ${{ github.event.inputs.stage || 'prod' }}

---

76-76: Optimize CDK bootstrap call.

The cdk bootstrap command runs unconditionally, which is redundant if the AWS environment is already bootstrapped. This adds unnecessary execution time.

Consider checking bootstrap status before running:

-          cdk bootstrap --require-approval never
+          # Check if already bootstrapped
+          if ! aws cloudformation describe-stacks \
+            --stack-name CDKToolkit \
+            --region "${{ env.AWS_REGION }}" > /dev/null 2>&1; then
+            echo "Bootstrapping CDK environment..."
+            cdk bootstrap --require-approval never
+          else
+            echo "CDK environment already bootstrapped."
+          fi

---

114-158: LGTM! Consider documenting timeout expectations.

The polling logic and state handling are well-implemented. The 90-minute timeout is reasonable for AMI builds, but consider documenting typical build times in comments to help future maintainers understand if this value needs adjustment.

Consider adding a comment:

       - name: Wait for AMI build completion
-        timeout-minutes: 90
+        timeout-minutes: 90  # Typical AMI builds complete in 20-30 minutes

---

178-226: Consider including stage information in release notes.

The release update adds AMI details but doesn't indicate which stage (prod/dev) the AMI was built for. This could be confusing if both stages are used.

Consider adding the stage to the release comment:

             const amiId = process.env.AMI_ID;
             const region = process.env.AWS_REGION;
+            const stage = process.env.STAGE;
             const releaseId = process.env.RELEASE_ID;

             const comment = `## 🚀 AMI Build Completed

+            **Stage:** \`${stage}\`
             **AMI ID:** \`${amiId}\`
             **Region:** \`${region}\`

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro