[aws-codepipeline-actions] EcsDeployAction: Can't reuse imported FargateService as service argument

Context: CDK-Pipeline in a shared account, which has a separate stage for ECS Deployments to target account(s).

Minimal code example (added 2020-09-22): https://github.com/michaelfecher/aws-cdk-pipelines-cross-account-ecs-deployment-issue/tree/cross-account-resources-import-fails

I can’t import an existing FargateService and reuse it in the EcsDeploy Action.

I also tried to use the BaseService to match the signature. However, it doesn’t provide an import method.

Alternatively, I tried to use a Stage variable to be able to pass the service to the EcsDeploy, but that failed with:

dependency cannot cross stage boundaries

Additionally, I tried the other method fromFargateServiceAttributes to retrieve the full context for the existing Fargate service. This approach fails, when calling the VPC fromLookup with All arguments to Vpc.fromLookup() must be concrete (no Tokens)

Guess it’s all related to the fact, that contexts/implicit dependencies can’t be resolved?

Reproduction Steps

This is the original issue:

       const fargateService = ecs.FargateService.fromFargateServiceArn(
          this,
          "FargateService",
          "ARNofFargateService"
        );
        cdkPipelineBackendDeployStage.addActions(
          new codepipeline_actions.EcsDeployAction({
            //  Property 'cluster' is missing in type 'IFargateService' but required in type 'IBaseService'.ts
            service: fargateService,
            actionName: "DeployActionBackend",
            })
        );

This is the alternative setup of the Fargate Import with fromFargateServiceAttributes:

const stage="dev";
const backendFargateService = ecs.FargateService.fromFargateServiceAttributes(
          this,
          `${stage}ImportedBackendService`,
          {
            cluster: ecs.Cluster.fromClusterAttributes(
              this,
              `${stage}ImportedCluster`,
              {
                clusterName: cdk.Fn.importValue("ExistingCluster"),
                vpc: ec2.Vpc.fromLookup(this, `${stage}ImportedVpc`, {
                  // error: All arguments to Vpc.fromLookup() must be concrete (no Tokens)
                  vpcId: cdk.Fn.importValue("ExistingVpcId"),
                 
                  // Alternative with name leads to 
                 // error: You can only specify either serviceArn or serviceName
                 // vpcName: "ShortNameVPC",
                }),
                securityGroups: [
                  ec2.SecurityGroup.fromSecurityGroupId(
                    this,
                    "importedSecGroup",
                    cdk.Fn.importValue("ExistingBackendSecurityGroup")
                  ),
                ],
              }
            ),
          }
        );

What did you expect to happen?

That the service argument is accepting the passed and imported Fargate Service object and can derive all already existing information, like the cluster, vpc, etc.

Additionally, the ECS deploy can redeploy the already created Fargate Service.

What actually happened?

Property 'cluster' is missing in type 'IFargateService' but required in type 'IBaseService'.ts(2741)
base-service.d.ts(180, 14): 'cluster' is declared here.
deploy-action.d.ts(37, 14): The expected type comes from property 'service' which is declared here on type 'EcsDeployActionProps'

Environment

• **CLI Version : **
• Framework Version: v.1.63.0 (CDK)
• Node.js Version: v12.18.2
• OS : Ubuntu
• Language (Version): TS 4.0.2

Other

---

This is 🐛 Bug Report

[skinny85]

Hello @michaelfecher ,

you’re using the Vpc.fromLookup function, which will require credentials to access your targetAccount. They’ll be needed only once, though, and then the results will be cached in cdk.context.json (which you should commit alongside your code), and then the credentials won’t be needed anymore.

Thanks, Adam

[innokenty]

Deploying with -e gives other error output during deploy, I suppose I need to check my privileges or something 😄

So tl&dr: the solution seems to deploy the pipeline with -e flag, so that it doesn’t try to deploy the auxiliary stack that we’re using for vpc/cluster/service lookup only!