Expand Codebuild to accept the new WebhookFilterType of WORKFLOW_JOB_QUEUED

[thutto]

Describe the feature

Recently AWS released a new Codebuild feature that enables it to be a managed runner for Github actions. Part of this was a new filter type being released ( WORKFLOW_JOB_QUEUED ).

Further reading can be found here.

Use Case

Expanding this enum will enable IaC consumers such as Terraform to release the needed changes on their side to enable this new feature.

Example of consumption can be found here

Proposed Solution

No response

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

AWS Go SDK V2 Module Versions Used

❯ go mod graph | grep "github.com/aws/"
github.com/aws/aws-sdk-go-v2 github.com/aws/smithy-go@v1.20.2
github.com/aws/aws-sdk-go-v2 github.com/jmespath/go-jmespath@v0.4.0

Go version used

go version go1.19.2 darwin/arm64

[RanVaknin]

Hi @thutto,

Thanks for reaching out. I see that this was released very recently. This might take a bit of time until the changes propagate through the SDK's release system.

Will check and let you know.
Thanks,
Ran~

[RanVaknin]

Hi @thutto ,

Thanks for your patience. After looking into this a bit deeper I can see why this is missing.

First of all to address your concern:

Part of this was a new filter type being released ( WORKFLOW_JOB_QUEUED ).

The enum in question WORKFLOW_JOB_QUEUED is not a new WebhookFilterType but rather a value that can be used as a pattern within the EVENT type in the WebhookFilter structure. WORKFLOW_JOB_QUEUED is one of the event types you can specify to trigger actions, and it is intended for use within the pattern string when configuring webhook events in AWS CodeBuild.

As for why this enum is missing from the SDK, the issue is with the dynamic nature of WebhookEventType. This enum's values are contingent upon the WebhookFilterType specified by the user, meaning its values can change based on context. Since the SDK's codegen system relies on static definitions that are directly referenced in the service's API operations (as parameters or response fields), and since WebhookEventType is context-dependent and does not have a static, universally applicable set of values clearly defined in any single API operation, it isn't generated in the SDK.

This is kind of an unusual modeling choice by the service team, but alas, the SDK team cannot "add" this enum type because the SDK is directly code generated from the API model of that service (you'll see that other SDKs also do not have that particular enum for the same reason).

Let me know if you have any questions.

Thanks,
Ran~