Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

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

See original GitHub issue

🐛 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.


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

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Reactions:1
  • Comments:13 (7 by maintainers)

github_iconTop GitHub Comments

eladbcommented, Sep 8, 2019

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.

rhboydcommented, Sep 7, 2019

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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

docker build - Docker Documentation
The docker build command builds Docker images from a Dockerfile and a “context”. A build's context is the set of files located in...
Read more >
Manage access tokens - Docker Documentation
Learn how to create and manage your personal Docker Hub access tokens to securely push and pull images programmatically.
Read more >
Overview of Docker Build - Docker Documentation
Overview of Docker Build. Docker Build is one of Docker Engine's most used features. Whenever you are creating an image you are using...
Read more >
Dockerfile reference - Docker Documentation
Docker can build images automatically by reading the instructions from a Dockerfile . ... The builder returns an error if it cannot find...
Read more >
Compose file build reference - Docker Documentation
Lack of a Dockerfile within this folder will throw an error. awesome/database docker image is built using backend sub-directory within Compose file parent ......
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found