I want SNS when branch is deleted. What to use? CodeCommit Trigger or CodeCommit Notification?
Trigger can be activated with branch deletion and Notification can be activated by branch delete also. What to select and why? Help me understand.
Although you can use both triggers/notifications but point to note is Triggers do not use CloudWatch Events rules to evaluate repository events.
Refer - https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-repository-email.html
Although you can configure a trigger to use Amazon SNS to send emails
about some repository events, those events are limited to operational
events, such as creating branches and pushing code to a branch.
Triggers do not use CloudWatch Events rules to evaluate repository
events.
CodeCommit trigger
Choose trigger if you are interested in one specific branch (or few named branches; up to 10) being deleted.
CodeCommit Notification
Setup notification if you want to get notified about any branch in your repository being deleted.
Related
What is the best way to migrate invocation of Lambda function from Cloudwatch event to Event Source Mapping(Triggers) with minimum risk and downtime?
Our application uses cloudwatch event rule to invoke Lambda at fixed rate, which then polls SQS queue to get messages, we want to automatically invoke the lambda using SQS trigger(ESM).
Brainstormed a couple approaches:
Option 1. Hookup both, trigger and cloudwatch event to existing Lambda, then slowly deprecate event rule.
Option 2. Using duplicate lambda with event source as SQS queue and divide the traffic, deprecate original lambda later.
Option 3. Add additional SQS(subscribed to same SNS) and Lambda pair which uses the trigger, deprecate the original later.
I am sure many teams might have done similar migration, any insights would be appreciated.
Your option 2 in the simpler way to switch.
Since you have CW event schedule, you lambda can execute maximum once per minute as the minimum precision for schedules is 1 minute.
Create new lambda
Set concurrency for old lambda to zero
Enable SQS trigger for new lambda
Delete event schedule trigger in old lambda
Requirement
I'd like to push DLQ messages to Lambda function periodically like cron.
Situation
I created a batch processing system using SQS and Lambda.
So, I also prepare DLQ(Dead Letter Queue) to store the failed messages.
AWS proposed re-run failed messages in the DLQ with Lambda trigger.
https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html
I'd like to re-run periodically and automatically like cron, but AWS doesn't show how to do that except for manually.
In case I re-run manually, I JUST map the lambda and the DLQ. It's all done.
After that, I can re-run messaging dynamically with Enable and Disable button.
Otherwise, it's more complicated because no API switching Enable and Disable of Lambda trigger.
boto3 API: create_event_source_mapping() and delete_event_source_mapping() are seemed to better way.
But delete_event_source_mapping() requires UUID of the event mapping. I think it indicates that I need any datastore like ElastiCache or else.
However, I don't wanna prepare other resources in this situation if possible.
My Solution
Cloud Watch Event call lambda.
lambda activate(Enable) event source mapping using create_event_source_mapping().
lambda deactivate(Disable) event source mapping using delete_event_source_mapping()
It looks good to me at first, but in 3rd process lambda want to know UUID from the 1st event. I think this case needs datastore including UUID.
Do you have any solutions without datastore?
Thanks.
I articulate the question as follows:
Is the EventBridge event relayed to the ECS Task? (I can't see how much useful it could be if the event is not relayed).
If the event is relayed, then how to able to extract it from within say a Node app running as Task.
Some Context is Due: It is possible to set an EventBridge rule to trigger ECS Fargate Tasks as the result of events sourced from, say, CodeCommit. Mind you, the issue here is the sink/target, not the source. I was able to trigger a Fargate Task as I updated my repo. I could have used other events. My challenge resides in extracting the event relayed (in this case, repository name, commitId, etc from Fargate.)
The EventBridge documentation is clear on how to set the rules to trigger events but is mum on how events can be extracted - which makes sense as the sink/target documentation would have the necessary reference. But ECS documentation is not clear on how to extract relayed events.
I was able to inspect the metadata and process.env. I could not find the event in either of the stores.
I have added a CloudWatch Log Group as a target for the same rule and was able to extract the event. So it certainly relayed to some of the targets, but not sure if events are relayed to ECS Task.
Therefore, the questions arise: is the event relayed to the ECS Task? If so, how would you access it?
Notifications: https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-repository-email.html
Triggers: https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-notify.html
The official document states that for CodeCommit repository 'events which follow CloudWatch Event Rules' (like pull requests), we use Repository Notifications.
Whereas for CodeCommit repository events which are just 'operational events' (like creating branches, pushing code to a branch), we use Repository Triggers.
I don't understand the difference between 'events which follow CloudWatch Event Rules' and 'operational events'. For me, both pull requests and pushing code to branch seem similar events.
Thus, confused between why we need both Repository Notifications and Repository Triggers.
I have asked the same question today and I found this on docs:
Repository notifications are different from repository triggers. Although you can configure a trigger to use Amazon SNS to send emails about some repository events, those events are limited to operational events, such as creating branches and pushing code to a branch. Triggers do not use CloudWatch Events rules to evaluate repository events. They are more limited in scope. For more information about using triggers, see Manage Triggers for a Repository.
IMO, AWS documentation has not clearly stated the difference between notification and triggers and cloudwatch events. Here is my understanding :
Notifications should be used for literal notification and not for taking action based on them.
Triggers are supposed to initiate action. So, if I need to invoke some service based on this event on which trigger is based, I would do that and hence the option to integrate Lambda service. In a way to add automation after codecommit events.
However, Cloudwatch Events provide a wide variety of integration option for codecommit events which are not available with trigger.
AWS CodePipeline now supports GitHub WebHook, but by default
every time code is pushed(changed) on the master branch, CodePipeline is triggered.
However, I only want it to run when I actually publish a release.
So, I manually configured the auto-generated GitHub WebHook as follows:
(Uncheck Pushes, check Releases)
but after the configuration, CodePipeline is not kicked any more.
(When I check Pushes again, it starts watching every pushes again)
Does it only watch Pushes action?
If it does, is there any other way to kick CodePipeline by GitHub release actions?
CodePipeline's webhooks were designed to handle push events, but I think there's no reason why you shouldn't be able to configure the CodePipeline webhook to trigger on release events. No information from the webhook invocation is actually used as part of the source action, so you could trigger it from anything.
The reason it's not working is probably because of how your webhook filters are configured.
Take a look at the ListWebhooks API to see how your webhook is configured.
This page describes how the filters and authentication configuration is used to match github events to decide whether to trigger a pipeline execution or not.