aws-ecs-deploy pipe reports success when ECS deployment circuit breaker rolls back

Michael Halligan

I'm using the atlassian/aws-ecs-deploy:1.15.0 pipe in Bitbucket Pipelines to deploy to an ECS service that has the deployment circuit breaker enabled with automatic rollback. I've hit a silent-failure mode and want to confirm whether there's a supported way to make the pipe fail the build when it happens.

Repro:

1. Pipeline step invokes atlassian/aws-ecs-deploy:1.15.0 with FORCE_NEW_DEPLOYMENT: 'true' and WAIT: 'true'.
2. The new task fails to start and never becomes healthy.
3. ECS's circuit breaker marks the new deployment FAILED and automatically rolls the service back to the previous task definition. The previous tasks come back up healthy.
4. Because the service returns to a steady state with the desired number of running tasks and a single PRIMARY deployment, the wait that the pipe performs returns success.
5. The pipe exits 0 and the Bitbucket step reports green, even though the deployment I just pushed never actually ran — the service is running the previous image.

Questions:

1. Is there a supported flag or configuration on aws-ecs-deploy that causes the pipe to fail the step when the new deployment's rolloutState ends in FAILED, or when the circuit breaker rolls back? I don't see one in the current docs.
2. Does the pipe inspect the new deployment's rolloutState at all, or does it rely solely on a services-stable wait plus a running-count check? If the latter, is there a roadmap item to make it circuit-breaker-aware?
3. Is there a recommended pattern from Atlassian for detecting a circuit-breaker rollback from within the pipe — for example, capturing the deployment ID returned by the update call and polling for that specific deployment's rolloutState until it reaches COMPLETED or FAILED?
4. If there is no supported way to do this with the pipe today, is the recommended path to replace the pipe with a custom script that performs its own rolloutState poll, or is there an Atlassian-maintained alternative I should use instead?
5. On a related note, do you have guidance on surfacing the last N ECS service events in the pipeline log when a deploy fails, so the cause of the rollback is visible without digging into a separate console?

Arkadiusz Wroblewski

Hello and welcome to Atlassian Community @Michael Halligan 

What you observed matches the standard ECS services-stable waiter, which considers a service stable when there is one deployment and the running task count equals the desired count.

For this requirement, I'd move deployment to AWS CLI instead of aws-ecs-deploy plus a waiter. Atlassian's ECS docs recommend the CLI for advanced scenarios needing more control.

AWS now exposes service deployment history through currentServiceDeployment / describe-service-deployments

For logs, print latest ECS service events on deployment failure:

`aws ecs describe-services --cluster "$CLUSTER" --services "$SERVICE" --query 'services[0].events[:10].[createdAt,message]' --output table`

If you need more detailed answer or inspection, if I will be in your shoes I would open support ticket.

Best,

Arek 🤠