AppRunner Deployment & Postman Test Automation

This wiki documents the work done for automating AWS AppRunner deployments and running Postman API tests in CircleCI. It explains the design, key scripts, race condition handling, and why each update was necessary. 📌 Background Our goal was to: Automate the deployment of services to AWS AppRunner as part of CI/CD. Run Postman API collections against the deployed AppRunner service. Ensure race conditions (multiple jobs triggering deployments at once) are safely handled. Use S3 as metadata storage for AppRunner service details (URL, ARN, Service Name, and Lock file). Support test retries and automatic cleanup after runs. 🔧 Key Components

1. deploy_apprunner_ inline.sh This script is responsible for creating the AppRunner service. Changes made: Added lock file mechanism in S3 to prevent duplicate deployments. Added retry logic to handle AppRunner creation race conditions. Writes service metadata (.app_url, .service_name, .service_arn and Lock file) to S3 for use by test jobs. Health check validation before tests proceed. Sets CloudWatch log retention policy automatically. Why: Prevents duplicate AppRunner deployments when multiple jobs start at the same time. Ensures test jobs always get the correct, fresh AppRunner metadata.

2. RunPostmanTestTemplate This job template runs Postman collections against the deployed AppRunner service. Changes made: Downloads metadata (.app_url, .service_arn, .service_name) from S3. If lock exists, waits until metadata appears . If no service exists, triggers deployment . Uses a flag .deployed_by_this_job to mark jobs that actually deployed. Runs Postman collections with retry and logs results. Persists logs as CircleCI artifacts. Why: Ensures that only one job performs deployment, while others wait for metadata and then run tests. Prevents unnecessary duplicate deployments.

3. DestroyAppRunnerService This job cleans up resources after tests. Changes made: Downloads .service_arn from S3. Deletes the AppRunner service. Cleans up lock file and AppRunner metadata from S3. Cleans up temporary .noop markers from logs. Why: Ensures that subsequent runs always start with a clean slate. Prevents leftover metadata from pointing to a deleted AppRunner service. 🧩 Race Condition Handling A key challenge was avoiding race conditions when multiple jobs tried to deploy AppRunner simultaneously. Solution: A lock file is written to S3 when a deployment starts. Other jobs detect the lock and wait until .app_url metadata is available. If an AppRunner service already exists, jobs skip redeployment and wait for metadata. Jobs only mark themselves as deployed_by_this_job if they really deployed. This ensures that only one deployment happens , while others wait and then proceed safely. ✅ Current Flow First Cycle (Fresh Deployment) No lock → Deployment job creates AppRunner. Writes metadata to S3. Runs health check. Runs Postman tests. Subsequent Cycles (Re-runs) Lock or existing service detected. Jobs wait for metadata in S3. Jobs fetch .app_url. Tests run against the existing AppRunner. Cleanup Destroy job deletes AppRunner. Cleans up lock and metadata from S3 This setup ensures that deployments and tests in CircleCI are consistent, race-free, and resilient .