Not super familiar with the codebase, but it seems like (other than some tests which use docker CLI) this is the main class/file that would need to be refactored to support other CLIs. Perhaps an extra argument to the constructor to specify the "root CLI command" could work?

There is a CDK_DOCKER env var to do the drop-in Docker replacements

Searching CDK_DOCKER and found there is only one more place using it besides of the one @pendo324 mentioned. -> Docker is also used in Bundling.

Seems these two are the only places using Docker except tests. I will do some gap analysis for both files.

CDK_DOCKER works very well, but we need better documentation around this.
Some more advanced container option might be incompatible with the current feature set of finch.

I have PR coming up that will add better support for building the AWS CDK with finch (as in contributing, not using).

We would also welcome a PR that adds an option to set CDK_DOCKER (probably needs a different name) via cdk.json and as a cli flag.

My PR is up
#23855

Here are the current gaps for Finch drop-in replacement I identified with best effort.

runfinch/finch#195
runfinch/finch#194
runfinch/finch#192
runfinch/finch#187

Should we log the failed finch command in e2e tests with CDK_DOCKER=finch so we may get a full list of gaps?

I also would like to discuss the testing strategy. The tests can not only validate the current change is right, also ensure it for future versions. To test the Finch integration, Finch needs to be installed in the test environment and the scenarios will be all the existing scenarios with the CDK_DOCKER=“finch” environment variable.

• Option 1 Add tests with finch CDK_DOCKER variable in CDK CI that block CDK release. This implies an explicit support of Finch in CDK.
• Option 2 Add tests with finch CDK_DOCKER variable that are only informative. If it is caught, CDK can document the maximum Finch-supported CDK version, and request feature parity in Finch as soon as possible.
• Option 3 Not add tests with finch CDK_DOCKER variable in CDK CI. CDK Finch users need to handle the testing by themselves.

As Finch is in pre v1.0, maybe we can start from Option 2 to catch most of the issues for users, and move to Option 1 at some point like when Finch is v1.0.

@ningziwen I'm okay with option 2 in general. However we currently run the build pipeline in AWS CodeBuild which doesn't support MacOS builds. At least as far as I can tell.
https://docs.aws.amazon.com/codebuild/latest/userguide/build-env-ref-compute-types.html

It might be easier to wait for Linux support.

The other problem is going to be that our builds are currently set up to fail fast. So as soon as an error occurs, the build will stop. We will need some changes to run a build that gathers all failures.

However we currently run the build pipeline in AWS CodeBuild which doesn't support MacOS builds

So CDK is not running e2e tests in macOS today? Is CDK open to add macOS Build by something like mac EC2?

It might be easier to wait for Linux support.

I feel that tests are passing in Linux may not ensure the tests are also passing in macOS.

Given that macOS Builds would be completely different than all our builds, I don't see us setting up builds for this.
At some point we had tentive plans to move PR builds over to GitHub Actions - which would be a much easier solution to support macOS. But I'm not sure where we are with that. It would certainly happen after the ongoing repo restructuring project.

I reckon the best way forward would be to set up a separate GitHub Action workflow that checks out aws/aws-cdk repo and runs the build and tests commands with required variations (better output, don't fail fast) on a schedule.

This issue has received a significant amount of attention so we are automatically upgrading its priority. A member of the community will see the re-prioritization and provide an update on the issue.

When running a full CDK build, finch will require access to $TMPDIR. This can be achieved with the following configuration:

~/.finch/finch.yaml

additional_directories:
    - path: /var/folders
    - path: /private/var/folders

Additional feature gap opened in Finch repo. runfinch/finch#243

I don't think we need to support "--build-arg flag without a value, in which case the value from the local environment will be propagated into the container being built", ticket in finch. This is because the CDK parses the --build-args as a key value pair and won't compile otherwise, so it's not possible to just pass an env to the build command in the --build-arg flag. Property definition.

CDK supports is added in Finch v0.9.0: https://github.com/runfinch/finch/releases/tag/v0.9.0

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.