(codebuild): AWS CDK 2.0 still defaults to LinuxBuildImage.STANDARD_1_0

[markusl]

AWS CDK 2.0 still defaults to LinuxBuildImage.STANDARD_1_0

Reproduction Steps

Define a codebuild.Project in a pipeline.

What did you expect to happen?

The default build image should be something that AWS actually supports.

What actually happened?

CDK 2.0 defaults to an outdated build image.

Environment

• CDK CLI Version : 2.0.0-rc.23 (build 1e54fb9)
• Framework Version: 2.0.0-rc.23 (build 1e54fb9)
• Node.js Version: 14
• OS :
• Language (Version): all

Other

---

This is 🐛 Bug Report

[markusl]

@peterwoodworth do you know if this is going to be included in AWS CDK 2.0?

[peterwoodworth]

I'm not sure - @skinny85 might know

[skinny85]

@markusl unfortunately, I don't have the bandwidth to take care of this. Unless you submit a PR to the v2-main branch making buildImage required, unfortunately this will probably not happen 😕.

[markusl]

@skinny85 well, it is a security consideration to use supported platforms, instead of old, insecure, and deprecated platforms by default.

I totally understand that there's a huge amount of different kinds of issues in your issue tracker but to me, it sounds weird that you expect library customers to take care of lifecycle updates of platform-level dependencies. In our company, we would like the library to default to the AWS recommended, standard and secure versions at all times.

[skinny85]

In our company, we would like the library to default to the AWS recommended, standard and secure versions at all times.

Unfortunately, that's kind of at odds with semantic versioning of a client-side library, so we're between a rock and a hard place (breaking backwards compatibility vs staying up to date).

[markusl]

@peterwoodworth any news on this? Could you consider this for CDK v3? :)

[peterwoodworth]

There are currently no plans for v3, so we can't really consider this for v3 quite yet. Also, we don't have an ETA on this.

I wonder if we could include this in v2 with feature flags?

[markusl]

@peterwoodworth Yep, I think that's the least you can do. It's really important that CDK libraries have sane defaults to officially supported CodeBuild images.

[markusl]

@peterwoodworth Hello again!

This issue still exists and a lot of people are seriously struggling with the AWS-provided default values that are not supported by AWS. Support for aws/codebuild/standard:5.0 is ending in a month and would be good to mark it as deprecated.

See also other related issues #23617 #23096 and #11960 which demonstrate why people are not having first-class experience at the moment.

[skinny85]

Maybe a feature flag? 😃

[markusl]

Maybe a feature flag? 😃

Sounds good. A feature flag to opt out of using the latest build image? :)

[skinny85]

Maybe a feature flag? 😃

Sounds good. A feature flag to opt out of using the latest build image? :)

I was actually thinking a feature flag that makes buildImage required 🙂.

[hoegertn]

Not sure that is a good idea. This would also mean that the buildImage needs to be required in all constructs using this like CDK pipelines or it would not change anything. For me one of the benefits of the CDK is having proven defaults instead of setting my own properties.

But I totally see that changing it also is a problem as it could be a breaking change.

[jsamuel1]

I definitely expected my new CDK pipeline to use a new image - so I was surprised when I got an AWS Health warning about the deprecation of standard/5.0 image on my new pipeline.

[vumdao]

Fixed by #24544 ?

[markusl]

Fixed by #24544 ?

Unfortunately no:

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

Line 560 in 236ecde

* @default BuildEnvironment.LinuxBuildImage.STANDARD_1_0

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

Line 1042 in 236ecde

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

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

Line 1022 in cea1039

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

[vumdao]

@markusl your ticket mentions cdk 2.0 and you're pointing issue from 1.0

[vumdao]

Just recognize that #24544 fixed for CDK pipeline only

[shellscape]

Landed here today with the same exact issue. Would love to see the team prioritize a good default here.