cdk-assets: extensibility

Description

Before a stack is deployed, the provisioner will prepare all of the assets required by the stack. The types of assets currently supported are zip, file, container-image.

There are cases where other asset types would be useful, like existing container images (use case below). Leaving aside that CloudFormation can already handle that (use case below), this seems like a perfect use case for Plugin support.

Proposal

Allow plugins to contribute new asset types for preprocessing before stack deployment.

Use Case

I am using an internal container registry as the master repository for all of my Docker containers (used across all AWS Accounts). During the build, we already have the credentials for the internal (non-aws hosted) container registry and the URI to the particular container.

I then create two stacks, the first of which contains the ECS Cluster and Repository definitions. The second stack creates the task definition and requires the cluster and Repository as input parameters.

Before the second stack deploys, it would be great if we could issue some type of docker push command since the URI and repository are known at that time. I know this could be done with CloudFormation using SecretsManager. But push the container to the repository before the stack deploys feels a little cleaner to me…

Proposed Solution

Allow plugins to contribute new asset types.

Other

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[benagricola]

Not sure if this is very helpful but I have a very similar use-case to this. I’d like to be able to run cdk inside a gitlab CI/CD process that does not have access to a local docker binary, or access to a docker.sock (for security reasons) to be able to build images.

I can build the images as part of the CI process (using kaniko for example) and these can then be outputted as a tar file or pushed to gitlab. Being able to hook the image build (in my case would be to no-op it) and the image push (to push the image from gitlab repo to the cdk-created ECR repo, probably using crane or something similar) would be amazing.

On language front - does this need to be defined? It might be a naïve suggestion but could you pass the path to an executable which handles the ‘build’ and ‘push’ part of the asset preparation?

At the moment the code calls docker build and push directly - could this functionality be moved into a ‘translation layer’ binary which is called by the cdk itself, and can be overridden if necessary?

It seems like there might be too many potential use cases there to take all of them into account with a single language choice imho.

[nmussy]

Another use-case would be a lambda plugin that transpiles a TypeScript function into JavaScript. What I’ve also done in the past is tree-shake and transpile with webpack and @babel/typescript to trim down the dependencies, which could also be useful for plain JS functions.

Anyway, I think it’s a great idea 👍