aws-codebuild: The default image of aws/codebuild/standard:1.0 results in slow provisioning times

[richardm]

Describe the bug

Running a Hello World CodeBuild Project consistently takes 2+ minutes to provision yet only seconds to execute. This appears to be due to the AWS CDK using aws/codebuild/standard:1.0 by default. According to the references below, the latest image for Ubuntu 18.04 is aws/codebuild/standard:4.0, and it appears that only the latest images are cached.

Expected Behavior

Per the AWS CodeBuild docs: "By default, projects use a small instance with an Ubuntu 18.04 image. You can use the environment property to customize the build environment."

I expected the default image to be cached since presumably most people new to the CDK (like me) would use the default. I further expected it to be the latest Ubuntu 18.04 image, which appears to be aws/codebuild/standard:4.0.

Current Behavior

The default image used is aws/codebuild/standard:1.0, which takes 2+ minutes to provision.

Reproduction Steps

return new Project(this, 'Project', {
  environment: {
    // Reproduce by not specifying any environment properties
  }
});

Possible Solution

I provided a value for the build image, and it reduced provisioning times to under 30 seconds, which is a substantial improvement:

return new Project(this, 'Project', {
  environment: {
    buildImage: LinuxBuildImage.STANDARD_4_0
  }
});

Additional Information/Context

No response

CDK CLI Version

2.51.1 (build 3d30cdb)

Framework Version

No response

Node.js Version

v14.18.2

OS

Mac OS Ventura 13.0.1

Language

Typescript

Language Version

No response

Other information

No response

[peterwoodworth]

This is defined here

aws-cdk/packages/@aws-cdk/aws-codebuild/lib/project.ts

Line 1042 in 3d30cdb

this.buildImage = (props.environment && props.environment.buildImage) || LinuxBuildImage.STANDARD_1_0;

Something like this we'd need to have a feature flag to adjust, in case anyone is using the default value intentionally and doesn't desire that to change

[richardm]

Is there a reference that documents the planned release schedule or planned end of maintenance for these codebuild/standard images? I found the AWS-codebuild-docker-images readme which claims that the codebuild/standard images below 4.0 are no longer maintained or updated, but it's unclear how much longer 4.0 will receive support. If the default gets changed to 4.0, I wonder if we will soon find ourselves back in this same situation of the default image not being cached and another round of breaking changes required to update the default. Perhaps if the default gets changed, it should be to 5.0 or later, but even that simply delays the need to repeat this process.

From an end user standpoint, I don't mind adding a couple of lines to use a different image. The issue is there was nothing warning me that I should not use the default settings -- or that they referred to an unsupported image. At minimum, this could this be called out more clearly in the docs.

How about also marking LinuxBuildImage.STANDARD_1_0 - LinuxBuildImage.STANDARD_3_0 as deprecated? That seems appropriate given that the images are no longer supported or maintained, and I see this has already been done for AMAZON_LINUX_2_ARM (though possibly for different reasons). That doesn't solve the problem for projects using the defaults, but it does provide a gentle nudge for those who at one point hard-coded the image value and just haven't gotten around to upgrading.

When I run cdk synth with the default environment settings, it informs me that I'm using the 1.0 image. How about having cdk synth or cdk deploy warn anyone using lower than 4.0 that the image they are using is no longer maintained and recommending an upgrade to 4:0 or higher? This would encourage everyone to update to a newer (cached) image without the downside of breaking changes. This is also a more sustainable long-term solution to this issue, since a LinuxBuildImage.MINIMUM_SUPPPORTED_VERSION const could be easily updated once 4.0 is no longer supported.

I'm happy to work on a PR for some of these changes but wanted to confirm direction first.

[peterwoodworth]

Thanks again for the request and your input. If you're still interested in continuing this discussion, let's do so in #16707

[github-actions]

⚠️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.