feat(scheduler-targets): eventBridge putEvents target

[WtfJoke]

An eventBridgePutEvents target was implemented similar to the already existing LambdaInvoke/StepFunctionStartExecution target.

I needed to change some properties and methods from Target.ts from private to protected so that the logic could be reused (hope that is ok).

Some design choices to outline (let me know if you disagree or have improvements I could take :) ):

1. PutEvents would accept multiple Entries (eg. an array), but I decided to support just one single event, because how Target is currently designed (to support only one target arn). It also aligns with the templated integration in the aws management console.
2. It throws an error in the constructor if the base prop input is used. All the props should be delivered by the new EventBridgePutEventsEntry. It felt not right for the developer experience to split the object (detail to input and source, detailType to EventBridgePutEventsEntry ).

Closes #27454.

---

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

[kaizencc]

Hi @WtfJoke! Thanks for another scheduler target! A few comments here and there, but I appreciate your dedication to this module :)

[kaizencc]

theres a section at the top of this readme that mentions what targets are available, can you put this and the stepfunctions one there please

[WtfJoke]

StepFunction was already there. I've added eventbridge. Thanks for pointing this out

Pull request has been modified.

[WtfJoke]

Hey @kaizencc
Thanks for the review! Appreciate the feedback. I've addressed most of your feedback, please have a look at it again.

Yeah I initially needed StepFunction for a Demo/Talk, so I was keen in contributing this back (after hacking it together on my demo repo) and figured its quiet straight forward to add more targets (Im thinking about adding the Universal target as well, but I could imagine this will be a bit harder) :D

[aws-cdk-automation]

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

[aws-cdk-automation]

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

[aws-cdk-automation]

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

[aws-cdk-automation]

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

[WtfJoke]

@kaizencc I've fixed the merge conflicts and rebased my changes. Please have a look at it.

[aws-cdk-automation]

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

[aws-cdk-automation]

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

[kaizencc]

Hi @WtfJoke, thanks for your continued patience here. I have a few more comments, but this is looking good!

[kaizencc]

I think we can type this better than a string. From the docs you've provided, the only thing that I see as a possible input here is "AWS API Call via CloudTrail". Lol. So here is what I propose:

readonly detailType: DetailType;

////


export class DetailType {
  public static API_CALL_VIA_CLOUDTRAIL() {
    return new DetailType('AWS API Call via CloudTrail');
  }

  public constructor (public readonly type: string) {}
}

This way, we can

a) give users an easy API to hit rather than getting the specific string correct (DetailType.API_CALL_VIA_CLOUDTRAIL),
b) provide space for future additions if we know of other valid detail types as static methods,
c) users can still specify whatever they want via new DetailType('my special type')

[WtfJoke]

Will do.

There seems to be more, but not documented which detail-type they emit.
I found only one additional example in the docs here "detail-type": "EC2 Instance State-change Notification"

Cant speak for others but our team uses only own detail types (e.g your point c).

For context:
I followed the existing EventBridgePutEvents implementation of the step function tasks package, which uses string as type (most likekly the type is identical).

[WtfJoke]

Introduced class DetailType as per request :)

[kaizencc]

Andddd I am now wavering on this suggestion. I still think it could be a good idea, but might be overengineered. I didn't see the nuance at first that most detail-types are user-owned, and then for events from AWS there maybe detail types with specific strings.

I think we should go back to using string here.

[WtfJoke]

I just dropped my last commit, which effectively reverts the change.

Pull request has been modified.

[WtfJoke]

@kaizencc Great to hear. Looking forward to getting this merged.

Would be glad if you can answer my questions, as im stuck in 2/3 review comments.

[WtfJoke]

@kaizencc I just dropped my last commit. Also rebased my changes on to latest main and fixed all the conflicts.

Please have a look :)

[aws-cdk-automation]

AWS CodeBuild CI Report

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

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

[kaizencc]

Thanks @WtfJoke and sorry for the many rounds of fruitless reviews :)

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[WtfJoke]

No worries :)