Also run MrApprovedLabel processor on (un)approved MR events
Context
Follow-up of !2690 (comment 1788939276)
merge_request.approval
webhook event is not triggered if merge_request.approved
is triggered (i.e. on MRs that have all the required approvals fulfilled). I noticed this in the production logs that /approve
and /unapprove
trigger respectively an merge_request.approved
and merge_request.unapproved
event:
{"name":"sucker_punch","hostname":"triage-web-deployment-7c7c7db45f-89zs6","pid":7,"severity":"INFO","time":"2024-02-26T08:59:42.276+00:00","message":"Event processing","dry_run":false,"event_class":"Triage::MergeRequestEvent","event_key":"merge_request.approved","event_payload":{"object_kind":"merge_request","event_type":"merge_request","user":{"id":10821571,"name":"David Dieulivol","username":"ddieulivol","avatar_url":"https://gitlab.com/uploads/-/system/user/avatar/
What does this MR do and why?
Expanding the reactions for the new processor to all approval/approved MR events.
Expected impact & dry-runs
These are strongly recommended to assist reviewers and reduce the time to merge your change.
See https://gitlab.com/gitlab-org/quality/triage-ops/-/tree/master/doc/scheduled#testing-policies-with-a-dry-run on how to perform dry-runs for new policies.
See https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/doc/reactive/best_practices.md#use-the-sandbox-to-test-new-processors on how to make sure a new processor can be tested.
Action items
-
If adding environment variables for reactive processors, update config/triage-web.yaml
and.gitlab/ci/triage-web.yml
-
(If applicable) Add documentation to the handbook pages for Triage Operations => - (If applicable) Identify the affected groups and how to communicate to them:
-
/cc @ person_or_group
=> -
Relevant Slack channels => -
Engineering week-in-review
-