Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -445,6 +445,7 @@ One of `yamlField` or `regex` is required.
| serviceDefinitionFile | string | The path ECS Service configuration file. Allow file in both `yaml` and `json` format. The default value is `service.json`. See [here](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html) for parameters.| No |
| taskDefinitionFile | string | The path to ECS TaskDefinition configuration file. Allow file in both `yaml` and `json` format. The default value is `taskdef.json`. See [here](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html) for parameters. | No |
| targetGroups | [ECSTargetGroupInput](#ecstargetgroupinput) | The target groups configuration, will be used to routing traffic to created task sets. | Yes (if you want to perform progressive delivery) |
| runStandaloneTask | bool | Run standalone tasks during deployments. About standalone task, see [here](https://docs.aws.amazon.com/AmazonECS/latest/userguide/ecs_run_task-v2.html). The default value is `true`. |

### ECSTargetGroupInput

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -445,6 +445,7 @@ One of `yamlField` or `regex` is required.
| serviceDefinitionFile | string | The path ECS Service configuration file. Allow file in both `yaml` and `json` format. The default value is `service.json`. See [here](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html) for parameters.| No |
| taskDefinitionFile | string | The path to ECS TaskDefinition configuration file. Allow file in both `yaml` and `json` format. The default value is `taskdef.json`. See [here](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html) for parameters. | No |
| targetGroups | [ECSTargetGroupInput](#ecstargetgroupinput) | The target groups configuration, will be used to routing traffic to created task sets. | Yes (if you want to perform progressive delivery) |
| runStandaloneTask | bool | Run standalone tasks during deployments. About standalone task, see [here](https://docs.aws.amazon.com/AmazonECS/latest/userguide/ecs_run_task-v2.html). The default value is `true`. |

### ECSTargetGroupInput

Expand Down
5 changes: 5 additions & 0 deletions pkg/app/piped/executor/ecs/ecs.go
Original file line number Diff line number Diff line change
Expand Up @@ -199,6 +199,11 @@ func runStandaloneTask(
return false
}

if !*ecsInput.RunStandaloneTask {
in.LogPersister.Infof("Skipped running task")
return true
}
Comment on lines +202 to +205

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to confirm, with this change, the task would not be "even" created at the time piped "sync" the ECS app. We can expect other triggers to start the tasks for us, is that right? In such case, how can that trigger specify the exact taskDefinition revision to use to create the ECS task 🤔 WDYT @kentakozuka @nnnkkk7

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can expect other triggers to start the tasks for us, is that right?

Yes. We need other triggers to start the task.

In such case, how can that trigger specify the exact taskDefinition revision to use to create the ECS task

AFAIK, EventBridge Scheduler allows us to select the latest revision or specific one to run.

Untitled (1)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, I understand that they allow us to do that, but the point is how actually dev can understand that which revision of taskdef is what they want (if they create it not of the time they commit the code change). Anw, it's just my concern on how actually this function could be used in usecase, look like it not really pipecd problem (if both of you agree with that way to select revision). Besides, maybe print out registered taskdef revision on stage log could help.


err = client.RunTask(
ctx,
*td,
Expand Down
3 changes: 3 additions & 0 deletions pkg/config/application_ecs.go
Original file line number Diff line number Diff line change
Expand Up @@ -54,6 +54,9 @@ type ECSDeploymentInput struct {
// Automatically reverts all changes from all stages when one of them failed.
// Default is true.
AutoRollback *bool `json:"autoRollback,omitempty" default:"true"`
// Run standalone task during deployment.
// Default is true.
RunStandaloneTask *bool `json:"runStandaloneTask" default:"true"`
}

func (in *ECSDeploymentInput) IsStandaloneTask() bool {
Expand Down
5 changes: 3 additions & 2 deletions pkg/config/application_ecs_test.go
Original file line number Diff line number Diff line change
Expand Up @@ -61,8 +61,9 @@ func TestECSApplicationConfig(t *testing.T) {
TargetGroups: ECSTargetGroups{
Primary: json.RawMessage(`{"containerName":"web","containerPort":80,"targetGroupArn":"arn:aws:elasticloadbalancing:xyz"}`),
},
LaunchType: "FARGATE",
AutoRollback: newBoolPointer(true),
LaunchType: "FARGATE",
AutoRollback: newBoolPointer(true),
RunStandaloneTask: newBoolPointer(true),
},
},
expectedError: nil,
Expand Down