Skip to content

Updated TimeoutInMinutes property for CodeBuild project - #35

Open
js37 wants to merge 1 commit into
aws-cloudformation:mainfrom
js37:main
Open

Updated TimeoutInMinutes property for CodeBuild project#35
js37 wants to merge 1 commit into
aws-cloudformation:mainfrom
js37:main

Conversation

@js37

@js37 js37 commented Sep 4, 2026

Copy link
Copy Markdown

Issue #, if available: None

Description of changes:

AWS::CodeBuild::Project TimeoutInMinutes has a manual patch pinning maximum: 480. AWS [raised the build timeout limit to 36 hours (2160 minutes) in June 2024](https://aws.amazon.com/about-aws/whats-new/2024/06/aws-codebuild-build-timeout-limit-increased-36-hours/), so the patch now rejects valid templates: any build timeout above 8 hours fails validation.

This corrects the value to 2160. QueuedTimeoutInMinutes stays at 480, which is still accurate. The two properties have different limits and target different shapes in the CodeBuild API model:

  • timeoutInMinutesBuildTimeOut, smithy.api#range {min: 5, max: 2160}
  • queuedTimeoutInMinutesTimeOut, smithy.api#range {min: 5, max: 480}

Why the value is updated rather than the override removed

PR #15 removed a stale Lambda Timeout/maximum instead of updating it, on the grounds that the smithy model now supplies the correct value. That approach does not work for CodeBuild.

The smithy generator only walks properties reachable from a create operation, which it derives from handlers.create.permissions (_get_create_operations, generators/smithy.py). The published aws-codebuild-project.json has an empty create.permissions array, so the generator matches zero paths for this resource and never writes a smithy.json for it:

AWS::CodeBuild::Project  create.permissions: []    -> 0 matched paths
AWS::Lambda::Function    create.permissions: [26]  -> 71 matched paths

The base schema is also unbounded (TimeoutInMinutes: {"type": "integer"}). Deleting the override would therefore leave the property with no maximum at all rather than falling back to 2160, and cfn-lint would stop flagging out-of-range values entirely. For the same reason, all four entries in this manual.json are load-bearing and none are redundant with smithy.

Verification

Assembled the schema locally with provider patches applied first, matching the build order:

TimeoutInMinutes:       {"maximum": 2160, "minimum": 5, "type": "integer"}
QueuedTimeoutInMinutes: {"maximum": 480,  "minimum": 5, "type": "integer"}

Existing tests pass, including TestPatchConflicts::test_no_manual_smithy_value_conflicts.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant