fix(ecr): incorrect format for rule pattern

[msambol]

Closes #29225.

---

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

[lpizzinidev]

Looks good to me 👍

[scanlonp]

Hey @msambol, just checking if this PR is ready to go, or the rule pattern is still giving you problems with the trigger on the Lambda.

No worries if not, just wanted to check in.

[msambol]

Hey @msambol, just checking if this PR is ready to go, or the rule pattern is still giving you problems with the trigger on the Lambda.

No worries if not, just wanted to check in.

The trigger isn't being created but I think we should address that in a separate PR.

[scanlonp]

Maybe I am missing some context. I see from the issue that the rule never matched. Does that mean the lambda trigger was never created, even before this PR?

[msambol]

Let me test it out again. When I first worked on this, it didn't. I'll follow up.

[msambol]

@scanlonp I just redeployed my integration test again. The EventBridge rule gets created, but the trigger on the Lambda does not get created. Once I manually add the trigger, I can get the Lambda to fire.

[shikha372]

@msambol Thank you for your contribution, would like to understand this issue better before reviewing , in the reference docs, resources[] field is not empty always eg. I see it is required for event type Event for a pull through cache action or Event for a completed image scan (basic scanning) .. how are we handling these cases ? let me know if my understanding is not correct

[msambol]

@msambol Thank you for your contribution, would like to understand this issue better before reviewing , in the reference docs, resources[] field is not empty always eg. I see it is required for event type Event for a pull through cache action or Event for a completed image scan (basic scanning) .. how are we handling these cases ? let me know if my understanding is not correct

In those cases, we always have detail.repository-name and we can match on those. See here for event pattern matching.

[shikha372]

Thank you @msambol , would also like to confirm if there are no issues with lambda trigger when we define the rule using eventbridge rule, I would also test at my end to understand the lambda trigger problem to see we are not impacting any existing functionality for the targets with this change.

[shikha372]

hey @msambol  ,
had a chance to reproduce this today, curious to know is there any specific reason to use bind here? I tried with the following code to register lambda function

const myLambdaHandler = new lambda.Function( stack, 'test', {
  runtime: lambda.Runtime.PYTHON_3_12,
  code: lambda.Code.fromInline('# dummy func'),
  handler: 'index.handler',
});

repoOnEvent.onEvent('OnEventTargetLambda', {
  target: new LambdaFunction(myLambdaHandler),
});

[msambol]

@shikha372 It was so long ago I'm not sure why I did that 🤦🏼‍♂️ Fixed per your recommendation—thanks!

[shikha372]

@shikha372 It was so long ago I'm not sure why I did that 🤦🏼‍♂️ Fixed per your recommendation—thanks!

Thanks, to confirm just ran the integration tests on my local and I can see the lambda trigger too with details as a filter

[msambol]

@shikha372 It was so long ago I'm not sure why I did that 🤦🏼‍♂️ Fixed per your recommendation—thanks!

Thanks, to confirm just ran the integration tests on my local and I can see the lambda trigger too with details as a filter

I see it as well: e457942. Thanks!

[aws-cdk-automation]

AWS CodeBuild CI Report

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

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

[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).