CodeBuild: buildStatusName does not work for batch builds

[jared-christensen]

Describe the bug

The buildStatusName property in AWS CodeBuild, which allows customization of the Bitbucket commit status name, does not work for batch builds. When a batch build is triggered, the commit status name defaults to "AWS CodeBuild $AWS_REGION ($PROJECT_NAME)", ignoring the custom value provided in buildStatusName.

Regression Issue

• Select this option if this issue appears to be a regression.

Last Known Working CDK Version

No response

Expected Behavior

The buildStatusName value should be applied, and the Bitbucket commit status should reflect the custom name, even for batch builds.

Current Behavior

The Bitbucket commit status name defaults to "AWS CodeBuild $AWS_REGION ($PROJECT_NAME)", and the custom buildStatusName value is ignored for batch builds.

Here’s an example of the issue in Bitbucket:

• The build highlighted in the image is a batch build, and you can see that the buildStatusName property is not respected—it uses the default naming convention.

• The other builds in the list are regular CodeBuilds, where the custom buildStatusName works as expected.

Reproduction Steps

dwp-pr-e2e.ts.zip

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.173.3 (build 00db01f)

Framework Version

2.173.3

Node.js Version

22.12.0

OS

15.2 (24C101)

Language

TypeScript

Language Version

5.5.4

Other information

The AWS CDK documentation for buildStatusName does not mention any differences in behavior between regular builds and batch builds.

[ashishdhingra]

@jared-christensen Good morning. Thanks for opening the issue. Below is the analysis:

• Per AWS::CodeBuild::Project BuildStatusConfig, Context property Specifies the context of the build status CodeBuild sends to the source provider. The usage of this parameter depends on the source provider.. For Bitbucket, this parameter is used for the name parameter in the Bitbucket commit status.

  • Per Bitbucket: Create a build status for a commit, name parameter for commit status is an identifier for the build itself.
  • When we set buildStatusName on BitBucketSource, it correctly binds the buildStatusConfig here.

• Per AWS::CodeBuild::Project > BuildBatchConfig, it is a ProjectBuildBatchConfig object that defines the batch build options for the project.

  • In CDK code, when you invoke Project.enableBatchBuilds(), it just creates a _batchServiceRole if not already set. This role is used here to set buildBatchConfig when creating CfnProject resource.
  • There are other properties like BatchReportMode, etc. supported by ProjectBuildBatchConfig, which are not utilized by CDK as of now. For BatchReportMode property, default value per CloudFormation documentation is REPORT_AGGREGATED_BATCH. This might be using generic AWS CodeBuild $AWS_REGION ($PROJECT_NAME) format.

From CDK perspective, it is synthesizing the correct CFN template. Rest is handled by CloudFormation when CDK code is deployed and then by AWS CodeBuild service.

Based on general understanding of Context (buildStatusName) property, it corresponds to name parameter for commit status is an identifier for the build itself (not the complete batch). Since by default for ProjectBuildBatchConfig, BatchReportMode is used as REPORT_AGGREGATED_BATCH, it could have used generic AWS CodeBuild $AWS_REGION ($PROJECT_NAME) format. I would suggest opening issue in https://github.com/aws-cloudformation/cloudformation-coverage-roadmap repository to get inputs from CloudFormation team for this behavior.

I'm unsure if in your use case you would like to set BatchReportMode to REPORT_INDIVIDUAL_BUILDS and if it would give the your desired behavior; currently, the only way to set it could be by using a raw property override as demonstrated below:

const cfnProject = project.node.defaultChild as codebuild.CfnProject;
cfnProject.addPropertyOverride('BuildBatchConfig.BatchReportMode', 'REPORT_INDIVIDUAL_BUILDS');

Thanks,
Ashish

[github-actions]

This issue has not received a response in a while. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.

[jared-christensen]

It actually started working, I destroyed my stack and then redeployed it and it started working.

[ashishdhingra]

It actually started working, I destroyed my stack and then redeployed it and it started working.

@jared-christensen Thanks for the confirmation. Please confirm if we could close this issue. The analysis in #32686 (comment) was based on some assumptions since the minimal CDK code was not provided for reproduction.

[jared-christensen]

yes it can be closed

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.