chore: support contributing to the AWS CDK using alternative container clients

[mrgrain]

The AWS CDK uses docker for a feature subset related to building assets.
For users, we already support the CDK_DOCKER env variable to change the container client at runtime.
However contributing to the AWS CDK currently still requires a contributor to have docker installed.

This PR extends the support for the CDK_DOCKER env variable to contributor tooling.
For example one can now run:

CDK_DOCKER=finch ./scripts/foreach.sh "yarn build"
CDK_DOCKER=finch ./scripts/foreach.sh "yarn test"

When using finch, the following packages do still fail tests, due to known feature gaps:

@aws-cdk/aws-ec2
@aws-cdk/aws-lambda
@aws-cdk/aws-lambda-go
@aws-cdk/aws-lambda-python
@aws-cdk/aws-lambda-nodejs
@aws-cdk/aws-s3-deployment

---

All Submissions:

• Have you followed the guidelines in our Contributing guide?

Adding new Construct Runtime Dependencies:

• This PR adds new construct runtime dependencies following the process described here

New Features

• Have you added the new feature to an integration test?
  • Did you use yarn integ to deploy the infrastructure and generate the snapshot (i.e. yarn integ without --dry-run)?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[gitpod-io]

[MrArnoldPalmer]

I believe this will resolve #16209, linking for posterity.

[ningziwen]

The following packages do currently fail tests, presumingly due to some incompatibility of finch with Docker features. What exactly, will require further investigation.

Is it possible to log the finch commands when they fail? We can probably get a full list of the imcompatible gap from this.

[ningziwen]

Is the "build" in this PR mean the build of CDK binary? (as I saw you run yarn build for each in the PR description)

If we add CDK_DOCEKR to yarn build, does it mean CDK will have different binaries for each container client?

[RomainMuller]

Is the "build" in this PR mean the build of CDK binary? (as I saw you run yarn build for each in the PR description)

If we add CDK_DOCEKR to yarn build, does it mean CDK will have different binaries for each container client?

There is no such thing as a CDK binary... Anyhow, this is a runtime-change... the use of yarn build here was to validate that the tests all still pass when using finch.

@mrgrain this makes me think we should fast-follow with a PR to ensure we run integration tests with both Docker & Finch (at least the container-using ones).

[mrgrain]

I believe this will resolve #16209, linking for posterity.

@MrArnoldPalmer I don't think it does. #16209 talks about how podman isn't fully compatible with docker and so a few docker commands we currently use might need adjustment to be podman compatible. It's similar to how finch has feature gaps.

[kaizencc]

lgtm

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[MrArnoldPalmer]

@mrgrain I took it as "provide a way to swap out docker for something else" whether that something else is 100% compatible with all the things we need it to do is kinda hard to control. For podman specifically we can test it, but regardless you're right lets keep it open for now.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: eb9133f
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[ningziwen]

"Make sure finch is running"