Skip to content

(EcsDeployAction): define service attributes instead of service itself. #17911

@tobytipton

Description

@tobytipton

Description

EcsDeployAction should allow passing of a serviceName, clusterName, region and possibly account or requiring role, instead of requiring the service which is an IBaseService to set the CodePipeline Configuration and region.

This will allow for using EcsDeployAction to have better support in the CodePipeline API where a you typically would define the ECS service/cluster in a stack inside of a stage.

This would also better support having one pipeline which creates the ECS service/cluster and another pipeline which deploys updated code to the stack.

Use Case

Typical use case is to have a pipeline which defines a stage which has a stack to create the ECS service. That ECS service needs to be deployed to via EcsDeployAction, to do that you need need to pass in the service. Passing the service which is defined in the stack in the pipeline stage results in dependency cannot cross stage boundaries.

The other use case is to have one pipeline which create the ECS service infrastructure and another pipeline which handles the deployments to the ECS deployment via the EcsDeployAction.

Proposed Solution

Currently EcsDeployAction takes a service as an IBaseService which based on the service determines the ClusterName, ServiceName for the CodePipeline Action Configuration. The service is also used to determine the region for the CodePipeline Action.

The proposed solution would be to make service optional, if the combination of serviceName, clusterName, region and role is passed in as props. There would need to be a check to ensure either service or the combination of service attributes is passed in, to ensure service doesn't override the attributes.

Most likely using an property of serviceAttributes which requires serviceName, clusterName and making region as an optional property to be leveraged only when the serviceAttributes are passed in.

Other information

No response

Acknowledge

  • I may be able to implement this feature request
  • This feature might incur a breaking change

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions