-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(codebuild): attribute-based compute type for Fleet #32251
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request
. Additionally, if clarification is needed add Clarification Request
to a comment.
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #32251 +/- ##
=======================================
Coverage 80.54% 80.54%
=======================================
Files 106 106
Lines 6954 6954
Branches 1287 1287
=======================================
Hits 5601 5601
Misses 1175 1175
Partials 178 178
Flags with carried forward coverage won't be shown. Click here to find out more.
|
CodeQL job has failed, but this is caused by automatically generated test code and I think this is not a problem. |
I swear I searched for issues and PRs before starting #32574 🤦 I'll close mine and give yours a review today |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had a quick first look by comparing our implementations, I'll try again with a more neutral outlook later. Thanks!
disk: props.computeConfiguration.disk?.toGibibytes(), | ||
machineType: props.computeConfiguration.machineType, | ||
memory: props.computeConfiguration.memory?.toGibibytes(), | ||
vCpu: props.computeConfiguration.vCpu, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Despite what the CloudFormation documentation says, the numeric props are not optional, see https://github.com/nmussy/aws-cdk/blob/6120d8f54103f81c4ec601221c1f56e5a4549236/packages/%40aws-cdk-testing/framework-integ/test/aws-codebuild/test/integ.project-fleet-attribute-based-compute.ts#L67-L73
Could you give them a default value, like this for example, and add an integ with just { machineType: GENERAL }
?
@@ -138,13 +196,37 @@ export class Fleet extends Resource implements IFleet { | |||
throw new Error('baseCapacity must be greater than or equal to 1'); | |||
} | |||
|
|||
if (props.computeConfiguration) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also had this validation to make sure the user saw how ATTRIBUTE_BASED_COMPUTE
worked, leaving it up to you if you want to add it as well:
if (props.computeConfiguration) { | |
if (props.computeType === FleetComputeType.ATTRIBUTE_BASED && | |
(!props.computeConfiguration || Object.keys(props.computeConfiguration).length === 0)) { | |
throw new Error('At least one compute configuration criteria must be specified if computeType is "ATTRIBUTE_BASED"'); | |
} | |
if (props.computeConfiguration) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're missing a getter for the fromFleetArn
Import
class:
public get computeConfiguration(): FleetComputeConfiguration | undefined {
throw new Error('Cannot retrieve computeConfiguration property from an imported Fleet');
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additional nits
Something I was lacking as well was the ability to communicate to the user the exact instance type that will be selected. From what I could tell, it's only given out by the web console, and cannot be retrieved via the API, prior or post fleet creation. Even if we reverse engineered the selection algorithm, we would encounter the following issues:
So overall, not great DX, but not much we can do from our end |
Co-authored-by: Jimmy Gaussen <[email protected]>
Co-authored-by: Jimmy Gaussen <[email protected]>
Thanks @nmussy! I'll update my PR later as I'm a bit busy right now. |
@nmussy Thank you very much for your thorough review and detailed feedback. I believe I have addressed all the points you mentioned. I plan to check later whether the CI passes successfully. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More nits, sorry 😅
if (!Token.isUnresolved(vCpu)) { | ||
this.validatePositiveInteger(vCpu, 'vCPU count'); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could move the Token.isUnresolved
check to validatePositiveInteger
, it's a little cleaner and it can't hurt the other two to validate them as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are absolutely right. I have made the corrections!
@@ -125,6 +191,7 @@ export class Fleet extends Resource implements IFleet { | |||
public readonly environmentType: EnvironmentType; | |||
|
|||
constructor(scope: Construct, id: string, props: FleetProps) { | |||
super(scope, id, { physicalName: props.fleetName }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just noticed this addition, thanks I'd missed the physicalName
in my original implementation. Wouldn't something like this be preferable though, I don't see a reason not to give Resource
the rest of the props?
super(scope, id, { ...props, physicalName: props.fleetName });
const diskGiB = computeConfig?.disk?.toGibibytes() ?? 0; | ||
const memoryGiB = computeConfig?.memory?.toGibibytes() ?? 0; | ||
const vCpu = computeConfig?.vCpu ?? 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably a good idea to add a comment to explain why we need to have these default values here as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Your PR had an excellent comment, so I used it as it was.
// Despite what the CloudFormation schema says, the numeric properties are not optional.
// An undefined value will cause the CloudFormation deployment to fail, e.g.
// > Cannot invoke "java.lang.Integer.intValue()" because the return value of "software.amazon.codebuild.fleet.ComputeConfiguration.getMemory()" is null
/** | ||
* The amount of disk space of the instance type included in your fleet. | ||
* | ||
* @default 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if it's necessary to tell the user we set the default value to 0, same with the CloudFormation bug explanation in the JSDoc. It's a bit confusing and shouldn't affect them. Despite the workaround, in effect we still have an unset value and the instance is selected according to the other criteria
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. I also borrowed the description from your PR.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Issue # (if applicable)
None
Reason for this change
AWS Codebuild supports for creating Fleet with attribute based compute type.
https://docs.aws.amazon.com/codebuild/latest/userguide/fleets.html#fleets.attribute-compute
You can specify minimum vCPU, disk and memory sizes. Codebuild automatically selects the instance type based on the compute configuration.
Description of changes
Add
computeConfiguraion
prop toFleetProps
.Description of how you validated changes
Add both unit and integ tests.
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license