feat(ecs): support container version consistency

[isker]

Issue # (if applicable)

Closes #32202.

Reason for this change

Support the new ECS::TaskDefinition ContainerDefinition VersionConsistency property. This is a simple enabled/disabled flag.

Description of changes

Add a simple enabled/disabled enum prop to the construct.

More consequentially, default the prop to disabled (instead of unset) if the container image is a CDK asset, for the reasons described in the comments.

Description of how you validated changes

Unit and integration tests.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

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

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.37%. Comparing base (946b748) to head (cb2995a).
Report is 82 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #32225   +/-   ##
=======================================
  Coverage   81.37%   81.37%           
=======================================
  Files         222      222           
  Lines       13693    13693           
  Branches     2412     2412           
=======================================
  Hits        11143    11143           
  Misses       2271     2271           
  Partials      279      279           

Flag	Coverage Δ
suite.unit	81.37% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
packages/aws-cdk	80.68% <ø> (ø)
packages/aws-cdk-lib/core	82.09% <ø> (ø)

[isker]

@iliapolo I'm not sure why you updated the branch, but it seems that the resulting CodeBuild CI job hanged or something, the GitHub check is stuck in pending.

[mazyu36]

Thank you for the contribution.
Some comments.

[aws-cdk-automation]

AWS CodeBuild CI Report

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

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

[mazyu36]

Thanks!

[GavinZZ]

Left one comment to help me understand.

[GavinZZ]

This seems like a weird usage, can you help me understand this syntax.
Also if it's public method, we should remove _.

[isker]

Thanks for reviewing.

can you help me understand this syntax.

This is optional chaining for invoking functions. I did it because evil code passes arguments to these functions that are in fact not ContainerDefinitions:

aws-cdk/packages/aws-cdk-lib/aws-batch/lib/ecs-container-definition.ts

Lines 621 to 626 in 7b5f5a5

	this.imageConfig = props.image.bind(this, {
	...this as any,
	taskDefinition: {
	obtainExecutionRole: () => this.executionRole,
	},
	});

So, _defaultDisableVersionConsistency can be undefined in spite of what TypeScript indicates.

Also if it's public method, we should remove _.

I see many @internal public methods that have leading underscores. I can remove it if you like, but it does not seem unusal.

https://github.com/search?q=repo%3Aaws%2Faws-cdk%20path%3Apackages%2Faws-cdk-lib%20%40internal&type=code

[GavinZZ]

This is optional chaining for invoking functions.

Thanks for the information! This is good to know.

Thanks for getting back to me. If it's @internal method, it's okay to stay public for internal constructs usage. However, I see in the unit test files that this method is also exposed to be used in CDK stacks. If we will allow that kind of usage, I think we should remove _.

[isker]

I see in the unit test files that this method is also exposed to be used in CDK stacks.

I'm not sure what you mean by "exposed to be used in CDK stacks." I'm not intending normal users to call this. In these tests, I'm just testing the behavior of _defaultDisableVersionConsistency on behalf of internal callers like those here in container-image.ts.