docker images: cannot use tokens in buildArgs - improve validation and errors

🐛 Bug Report

What is the problem?

We all know that this works as intended:

    const myLambda = new lambda.Function(this, 'MyLambda', {
      ...
      environment: {
        FOO: mySqsQueue.queueArn,
      },
    })

The SQS queue ARN token is evaluated as expected and its final value used. The following, however, does not work:

    const myImage = new ecrAssets.DockerImageAsset(this, 'MyImage', {
      ...
      buildArgs: {
        FOO: mySqsQueue.queueArn,
      },
    })

In the last example, the token is never expanded.

Environment

• CDK CLI Version: 1.7
• OS: all
• Language: all

[eladb]

I agree with @PeterBengtson that this is confusing, without knowing better, I would expect this to also work.

But, sadly, there is not much we can do in this particular case besides a runtime error (which I think would at least reduce some of the grief). Building on @jogold’s suggestion, maybe you can export a QUEUE_URL environment in a user-data script in your EC2 instance instead of baking it into the build image?

Tokens are pretty magical. They allow us to treat late-bound values as first class in all programming languages, and in many cases, they “Just Work” and users don’t need to understand their details. In some (hopefully edge cases), their magic “leaks” and we need to be more explicit about validation and user education.

I am repurposing this issue to improve the error message in case tokens are used for buildArgs.

[rhboyd]

To my mind, CDK is simply wrong here. The two examples above are structurally almost identical, and I see no reason why both examples shouldn’t evaluate their args in a similar way. Are you saying the current behaviour is intentional? If so, how should the code be written to resolve the args as expected?

A hospital and an office complex are structurally almost identical but you’d be advised against coming to work with a broken leg and expecting it to feel better when you leave.

A Docker container and a Lambda Function are rather different, even though they share a similar API. A Docker image needs to be built before it can be used, a Lambda function does not. It makes sense that building/deploying a Docker Image would involve more steps than building/deploying a Lambda Function. I would argue that building a Docker Image is closer to building an EC2 AMI than it is to packaging a Lambda Function.