You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The task definition was created by CloudFormation in the same stack, however, because the b/g deployment happens by CodeDeploy outside of CloudFormation, CloudFormation is probably not aware of the current revision number and it causes drift.
The Task Definition name in CloudFormation does NOT contain a revision number.
Expected Behavior
Either remove the TaskDefinition property from drift detection while the DeploymentController is of type CODE_DEPLOY, or make sure CloudFormation can update internally the revision number when DeploymentController is of type CODE_DEPLOY.
Observed Behavior
The revision number differs from the revision number configured in the stack, even though it's not specified in the template.
Test Cases
Create a Task Definition and ECS Service with DeploymentController type of CODE_DEPLOY and configure CodePipeline for CI/CD to trigger CodeDeploy, or do it manually.
Other Details
No response
The text was updated successfully, but these errors were encountered:
Name of the resource
AWS::ECS::Service
Resource Name
No response
Issue Description
There is an issue while using the DeploymentController of type CODE_DEPLOY which update the task definition revision number outside of CloudFormation.
The drift looks like this:
Expected: "TaskDefinition": "arn:aws:ecs:eu-west-1:xxxxxxxxx:task-definition/taskdef-qa-demo:2"
Actual: "TaskDefinition": "arn:aws:ecs:eu-west-1:xxxxxxxxxxxx:task-definition/taskdef-qa-demo:23"
Example code looks like this:
ECSServiceDemo:
Type: AWS::ECS::Service
Properties:
Cluster: !Sub cluster-${environment}-01
DeploymentController:
Type: CODE_DEPLOY
DesiredCount: 1
LaunchType: FARGATE
LoadBalancers:
- TargetGroupArn: !Ref TGDemo01
ContainerName: !Sub dkr-${environment}-demo
ContainerPort: 5022
NetworkConfiguration:
AwsvpcConfiguration:
AssignPublicIp: DISABLED
SecurityGroups:
- !Sub "{{resolve:ssm:/${environment}/security-group/id/sgr-${environment}-demo}}"
Subnets:
- !Sub "{{resolve:ssm:/${environment}/subnet/net-${environment}-app-01}}"
- !Sub "{{resolve:ssm:/${environment}/subnet/net-${environment}-app-02}}"
ServiceName: !Sub svc-${environment}-demo
TaskDefinition: !Ref TaskDefenitionDemo
The task definition was created by CloudFormation in the same stack, however, because the b/g deployment happens by CodeDeploy outside of CloudFormation, CloudFormation is probably not aware of the current revision number and it causes drift.
The Task Definition name in CloudFormation does NOT contain a revision number.
Expected Behavior
Either remove the TaskDefinition property from drift detection while the DeploymentController is of type CODE_DEPLOY, or make sure CloudFormation can update internally the revision number when DeploymentController is of type CODE_DEPLOY.
Observed Behavior
The revision number differs from the revision number configured in the stack, even though it's not specified in the template.
Test Cases
Create a Task Definition and ECS Service with DeploymentController type of CODE_DEPLOY and configure CodePipeline for CI/CD to trigger CodeDeploy, or do it manually.
Other Details
No response
The text was updated successfully, but these errors were encountered: