aws-cdk: asset staging: do not recurse into the output directory

🐛 Bug Report

What is the problem?

I have hit a corner case with the code related to copy directories. It’s going in recursively until Node can no longer handle such long file names.

https://github.com/aws/aws-cdk/blob/16eb65867b79798779bf98a0316b1a05915720f1/packages/%40aws-cdk/assets/lib/fs/copy.ts#L7-L18

The offending snippet is when I had a docker asset declared as follows:

        new DockerImageAsset(this, 'app-image-asset', {
            directory: '.',
            repositoryName: 'my-repo/app',
        });

Running cdk deploy showed me this error:

Error: ENAMETOOLONG: name too long, mkdir 'cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.7e4b3cc320bdf668daa4c0d065bb1a9841162c955cb702f7a01d7d3d7e88dbfe/cdk.out/asset.03918990104d8973acd2ad0abe022844192fcce618cf74f7734a7077f4111d1f'
    at Object.mkdirSync (fs.js:750:3)
    at copyDirectory (/mnt/sdb/ideaProjects/my-project/node_modules/@aws-cdk/assets/lib/fs/copy.js:39:16)
    at copyDirectory (/mnt/sdb/ideaProjects/my-project/node_modules/@aws-cdk/assets/lib/fs/copy.js:40:13)
    at copyDirectory (/mnt/sdb/ideaProjects/my-project/node_modules/@aws-cdk/assets/lib/fs/copy.js:40:13)
    at copyDirectory (/mnt/sdb/ideaProjects/my-project/node_modules/@aws-cdk/assets/lib/fs/copy.js:40:13)
    at copyDirectory (/mnt/sdb/ideaProjects/my-project/node_modules/@aws-cdk/assets/lib/fs/copy.js:40:13)
    at copyDirectory (/mnt/sdb/ideaProjects/my-project/node_modules/@aws-cdk/assets/lib/fs/copy.js:40:13)
    at copyDirectory (/mnt/sdb/ideaProjects/my-project/node_modules/@aws-cdk/assets/lib/fs/copy.js:40:13)
    at copyDirectory (/mnt/sdb/ideaProjects/my-project/node_modules/@aws-cdk/assets/lib/fs/copy.js:40:13)
    at copyDirectory (/mnt/sdb/ideaProjects/my-project/node_modules/@aws-cdk/assets/lib/fs/copy.js:40:13)

(Declaring the directory as its full path did not work neither.) This is quite a serious issue for me, personally.

A possible solution is to exclude cdk.out. I think it’s reasonable to assume that cdk.out name is reserved for this project.

As a temporary workaround for me, I’ve edited the code so that it looks like the following:

    const exclude = options.exclude || ['cdk.out'];

Another possible solution is to avoid recursion if we’ve already seen the directory in question.

Apparently, it’s an issue where the docker build context is the same path as the cdk project. That said, I’m not sure if the above is enough to reproduce the issue. When I comment the code to create the docker asset, the issue disappears (probably more of a symptom rather than the cause). I’ve checked if symlinks are the issue (apparently, it’s not)

Environment

CDK CLI Version: 1.6.1
OS: all
Language: all

About this issue

Original URL
State: open
Created 5 years ago
Reactions: 28
Comments: 18 (3 by maintainers)

Commits related to this issue

chore: ignore cdk out - https://github.com/aws/aws-cdk/issues/3899#issuecomment-888349479 — committed to phuwin95/cdk-fargate-docker-nextjs by phuwin 2 years ago

Most upvoted comments

I added cdk* to .dockerignore to get it working:

// Create Fargate Service
const fargateService = new ecs_patterns.NetworkLoadBalancedFargateService(
  this,
  'sample-app',
  {
    cluster,
    taskImageOptions: {
      image: ecs.ContainerImage.fromAsset('./') // blows up without cdk.out in .dockerignore
    }
  }
)

+86

BinaryShrub on Jan 30, 2020

I added cdk* to .dockerignore to get it working:

Don’t forget to check your cdk.json, it should contain:
{
  "context": {
    "@aws-cdk/aws-ecr-assets:dockerIgnoreSupport": true
  }
}
Otherwise .dockerignore is ignored 🤷

Mine seems to ignore my .dockerignore file anyway. Could be because I’ve changed to context dir but I have also tried adding the .dockerignore file to the root of my context

const lith = new lambda.DockerImageFunction(this, `${name}lith`, {
      code: lambda.DockerImageCode.fromImageAsset(path.join(__dirname, '../../../../'), { // root of monolith 
        file: 'packages/deployment-service/Dockerfile', // location of Dockerfile
        ignoreMode: IgnoreMode.DOCKER,
        exclude: [
          'cdk.out',
        ],
      }),
      vpc,
    })

Tried both ~/.dockerfile and ~/packages/deployment-service/.dockerfile. Not sure what else to try!

Edit

Ok so after some investigation: .dockerignore needs to be at the root of the monorepo in my case, in other words: at ../../../../. However I still have a related issue which I’m debugging

another edit

Figured it out. Paths are specified from the asset path. So I needed to be more specific however I’d prefer it if my dockerignore file excluded the cdk dir globally as I specified but hey ho

exclude: [
  'packages/deployment-service/cdk',
],

+12

bashleigh on Jul 28, 2021

I added cdk* to .dockerignore to get it working:

Don’t forget to check your cdk.json, it should contain:

{
  "context": {
    "@aws-cdk/aws-ecr-assets:dockerIgnoreSupport": true
  }
}

Otherwise .dockerignore is ignored 🤷

wdolek on Feb 17, 2021

This is a bug. It makes sense that when we copy assets into the output directory, we won’t descend into the same directory as we copy.

eladb on Sep 4, 2019

Saw this issue for a similar use case while using the aws-s3-assets module. I was trying to zip up my cdk project into s3 and use it to bootstrap CodeCommit. Excluding cdk.out seems to work.

const asset = new Asset(this, 'CodeAsset', {
      path: path.join(__dirname, '../'),
      exclude: [
        'node_modules',
        '.git',
        'cdk.out'
      ]
    });

askulkarni2 on Nov 21, 2019

Re: "@aws-cdk/aws-ecr-assets:dockerIgnoreSupport": true,

It looks like this is no longer necessary.

jsii.errors.JSIIError: Unsupported feature flag '@aws-cdk/aws-ecr-assets:dockerIgnoreSupport'. This flag existed on CDKv1 but has been removed in CDKv2. CDK will now behave as the same as when the flag is enabled.

stevemer on Mar 10, 2022

I am experimenting with polylith monorepo with components, bases, projects that looks similar to this…

├── .dockerignore << add */**/cdk.out
├── bases
│   └── ts
│       └── some-base-pkg
│           └── src
├── components
│   └── ts
│       └── some-component-pkg
│           └── src
└── projects
    └── ts
        └── some-project-pkg << running cdk deploy
            └── Dockerfile
            └── cdk.json
            └── src
            └── bin
                └── cdk-app.ts << cdk code

My cdk-app.ts includes some code like this

const asset = new cdk.aws_ecr_assets.DockerImageAsset(this, "some-id", {
  directory: "/my/project/root,
  file: "projects/ts/some-project-pkg/Dockerfile"
})

what worked for me was added */**/cdk.out to my root .dockerignore. Hope this helps someone!

robertIanClarkson on Mar 13, 2024

Seeing this issue pop up again in random repos 😦

Figured it out thanks to @bashleigh 's detailed comment! I ignored the entire cdk folder at the root and all was well

abury on Nov 30, 2023

This usually happens when you try to build an image from within a directory you want included in the image as well. It creates a recursive path that never ends.

rhboyd on Sep 1, 2019