Draft: Feature: Add Webhook To Intake

(WIP Description)

MR Purpose

The purpose of this merge request is to allow for the Triage Gem to take in GitLab's webhook payloads.

Reasoning

Currently, there is no way to use the Gem to get detailed information on comments. Having this ability will allow for anyone using the gem to create more in-depth automation around comments.

While comments were the main concern due to an internal project, this MR will allow for webhook data to be passed in from the following events:

1. Issue Events
2. Merge Request Events
3. Note (comment) Events
4. Note On An Issue Events
5. Note On A Merge Request Event
6. Note On A Commit Event

The ability to parse webhook payloads will allow for possibly using fewer resources when the gem runs. This is because the webhook is sent when an event happens, so we no longer need to limit our searches as we know that the event happened.

TL;DR it removes the need to list issues/MRs/etc.

Details

How It Works

Event Classes

All events that are parsed by the Gem will initially hit the BaseEvent class. All webhook payloads will have the project and user attributes parsed and put into the project and author fields for the final mappings.

• This is done because these two attributes are common between all Event types. The project field will be used to let the Gem know which project the event is coming from and in turn which project to run any actions on.
• This class then has a case statement to find which kind of event we are parsing (IssueEvent, MergeRequestEvent, or NoteEvent).
  • If an IssueEvent, then we will build out the hash to match the Single Issue API Response as close as we can.
  • If a MergeRequestEvent, then we will build out the hash to match the Single Merge Request API Response as close as we can.
  • If a NoteEvent then we will start by building out the note hash that will be filtered on via the Engine class.
    • The NoteEvent can have one of the following three sub-note categories
      • IssueNoteEvent
      • MergeRequestNoteEvent
      • CommitNoteEvent
    • These subcategories will build out the portions of the hash for each different note event type, respectively

Once the webhooks payload has been run through the event classes, it returns a hash that will mimic the API returns. This is then used to apply the same filters you would on API calls in the Engine class.

The idea behind this is that we will be able to make minimal changes to the Engine and Action classes in order to have webhooks become an intake form for the Gem.

Key Decisions Made

Discovery Still In Progress