Aws-cdk: CDK needs garbage collection for assets in the cdk.out directory

[nathanpeck]

Each time I run a CDK deploy I get a new asset in the asset's directory, and they seem to accumulate forever. Each asset folder is around 100 MB for me, so this quickly adds up to many GB of data. Here is a screenshot of it accumulating assets again after the last time I cleaned it out manually.

Ideally I would like a CDK configuration that would cause CDK to automatically garbage collect older asset files it no longer needs so I don't have to do it manually.

[RomainMuller]

Duplicated by #3749

[SomayaB]

Seems to be related to #1332

[SomayaB]

Hi @nathanpeck, thanks for submitting a feature request! This seems like a reasonable and helpful ask. We will look into this and someone will update this issue when there is movement.

[eladb]

I think that if users do cdk deploy we should actually emit cdk.out directory under /tmp instead of the project directory. When users deploy, cdk.out is just an intermediate artifact instead of a build artifact.

P.S. it should be something like /tmp/cdk.out.xxxx where xxxx is the hash of the project path (in order to allow multiple projects to co-exist on the same machine).

[nathanpeck]

@eladb I do worry that would reduce the visibility of the folder. Particularly in cases where I have multiple projects and for some reason my stacks aren't generating as expected I would hate to have to figure out which of the outputs inside my tmp folder is the right one.

I think while it is tempting to piggyback on the existing tmp cleanup behavior I don't think that it would be good for users of CDK, because it would end up being a hidden cache behavior that would be harder to clear when needed

[eladb]

If you do cdk synth output will still go to ./cdk.out which will give you visibility into exactly what's going to be used during deployment.

I am not sure I understand why you think putting intermediate (temporary) build artifacts is not a good use case for /tmp. Isn't that what /tmp is all about?

[nathanpeck]

@eladb I don't think of the build artifacts as temporary.

For example if I GCC compile I would expect my C++ files to turn into object files in a local path, not in the /tmp folder.

Or if I TypeScript compile I expect the resulting JavaScript to end up in the local directory, not in /tmp

From that perspective I see CDK to CloudFormation / assets as just another type of transformation, where I expect the resulting product to be local, not remotely cached

I'm not strictly opinionated on this, but it just feels somewhat strange to me if the cdk.out is located in a different folder outside of my project

[plumdog]

I found this issue from a different direction - I have some tests for my CDK code, and each time I run them it is building a new asset directory and putting it in /tmp, a new one for each test case. The assets for me happened to my 100s of MB, and soon my /tmp device was full.

I think I would expect that - by default - assets for test runs were deleted after the test run had completed, regardless of where they are stored.

[0xdevalias]

In the interim.. is it ok to just manually clear out anything in this folder (or even the whole folder)? I've left it building up for now as I wasn't sure if they were required somewhere down the line/for cdk diff support/etc.

[skinny85]

No, there should be no danger in removing cdk.out locally - it will be re-created next time CDK is executed.

[cloud-context]

Is is possible to change where these cdk.outxxxxx folders are created when running unit tests?

Our current plan is to have a process to clean up the /tmp folder after the tests are run but the problem is that this is on our build agent and it doesn't have a huge '/tmp` directory and potentially multiple builds running at once

[eladb]

Is is possible to change where these cdk.outxxxxx folders are created when running unit tests?

You should be able to specify the output directory when you create an App:

const app = new App({ outdir: '/tmp/foo' });
const stack = new MyTestStack(app, 'test');
// ...

[cloud-context]

I tried that setting for the app but it only seems to work for a synth command. When I run the CDK unit tests, there are multiple cdk.out directories created in the /tmp folder - I would like to change this directory if possible

[cjjenkinson]

Shorter term solution with bash find . -name 'asset.*.zip' -print0 | xargs -0 rm

I run this at the end of deployments

[cynicaljoy]

I think that if users do cdk deploy we should actually emit cdk.out directory under /tmp instead of the project directory. When users deploy, cdk.out is just an intermediate artifact instead of a build artifact.

P.S. it should be something like /tmp/cdk.out.xxxx where xxxx is the hash of the project path (in order to allow multiple projects to co-exist on the same machine).

I agree that the cdk.out should be moved to the tmp, I'd vote that the folder path be more verbose though: .e.g /tmp/aws-cdk/{projectHash}/cdk.out/ - we use the /tmp directory for a variety of things and selfishly I don't want to dozens of items in the root of /tmp for CDK alone.

In order to provide easy access to the cdk.out directory, you could either:

• Create a symlink in the project directory to the tmp dir
• Add a convenience method, e.g. cdk context get aws-cdk:outDir that would print the current project outdir so people could cd $(cdk context get aws-cdk:outDir) -- maybe not the most convenient, but I'd use it....meaning, I'd create an alias for it 😂