fix(ecs): detect rollback after service stability wait#859
fix(ecs): detect rollback after service stability wait#859ebihimself wants to merge 3 commits intoaws-actions:masterfrom
Conversation
ebihimself
changed the title
ebihimself
changed the title
|
Howdy @ebihimself , you're missing the changes for the |
|
Hey @NahutabDevelop, wazap? 🤠 Pushed! 🚀 |
| // even if the service is "stable", ECS may have rolled back to the | ||
| // previous task definition. In that case, the PRIMARY deployment | ||
| // will not match the task definition we expected to promote. | ||
| if (primaryDeployment.taskDefinition !== expectedTaskDefArn) { |
There was a problem hiding this comment.
There's a few parameters on the action for which this approach doesn't work. These are parameters called in the UpdateService call that trigger a deployment such as service-managed-ebs-volume or force-new-deployment
Basically, the task-definition would not change for these across deployments
There was a problem hiding this comment.
Makes sense! I will change the design. I think the safest way to check is to use the deployment ID.
There was a problem hiding this comment.
Yes, there might be a cleaner way, let me confirm
|
Hey @ebihimself wazap 🤠 - great work on this! Your PR was really helpful in thinking through the right approach. I ended up building on the same idea but switched to deployment ID comparison to address @s3cube's feedback about |
3 participants
Summary
Fixes #191 by validating the final ECS deployment after service stabilization.
Problem
The action currently waits for ECS service stability, but a failed deployment with deployment circuit breaker + rollback can still leave the service stable after ECS rolls back to the previous deployment.
Change
After
waitUntilServicesStable(...), callDescribeServicesand:FAILEDPRIMARYdeployment task definition is not the expected task definitionWhy
This ensures the action only succeeds when the intended deployment actually wins, rather than when ECS stabilizes via rollback.