This section exists primarily for reference purposes and documents all GitHub webhooks which can be handled by this gateway and their corresponding Brigade events that may be emitted into the Brigade event bus.
The transformation of a webhook into an event is relatively straightforward and subject to a few very simple rules:
-
In most cases, the event's
type
field will directly match the the webhook's type as determined by the value of theX-GitHub-Event
HTTP header.For the relatively few webhooks whose JSON payload contains an
action
field, the corresponding event will have atype
of the form<webhook type>:<action>
. For instance, for a webhook of typepull_request
with the valueopened
in theaction
field, the corresponding event would be of typepull_request:opened
. This approach is used because this gateway's creators have observed that when a webhook is qualified by anaction
field, the processing a script author might wish to perform for one value of theaction
field typically varies significantly from the processing they might wish to perform for some other value of theaction
field. By way of example, the logic required for handling a newly opened pull request might be quite different from the logic required for handling a pull request that's been closed. With this being the case, this gateway's creators considered it prudent to map each webhook type + action combination to its own distinct Brigade event type. -
With every webhook handled by this gateway being indicative of activity involving some specific repository, the name of the affected repository is copied from the webhook's JSON payload and promoted to the
repo
qualifier on the corresponding event. This permits projects to subscribe to events relating only to specific repositories. Read more about qualifiers here. -
For any webhook that is indicative of activity involving not only a specific repository, but also some specific ref (branch or tag) or commit (identified by SHA), this gateway copies those details from the webhook's JSON payload and promotes them to the corresponding event's
git.ref
and/orgit.commit
fields. By doing so, Brigade is enabled to locate specific code referenced by the webhook/event. The importance of this cannot be understated, as it is what permits Brigade to be used for implementing CI/CD pipelines. -
If this gateway is able to infer that a webhook pertains only to a specific Brigade project, this information will be included in the corresponding event's
projectID
field and will effectively limit delivery of the event to the applicable Brigade project. -
If this gateway is able to infer a human-friendly title for any webhook, the corresponding event will be augmented with values in its
shortTitle
andlongTitle
fields. -
For all webhooks, without exception, the entire JSON payload, without any modification, becomes the corresponding event's
payload
. The eventpayload
field is a string field, however, so script authors wishing to access the payload will need to parse the payload themselves with aJSON.parse()
call or similar. -
For the relatively few webhooks that are of particular importance when utilizing Brigade to implement CI/CD pipelines, all previous rules apply, but additional events may also be emitted into Brigade's event bus. See the CI/CD documentation for more details.
The following table summarizes all GitHub webhooks that can be handled by this gateway and the corresponding event(s) that are emitted into Brigade's event bus.
⭐️ symbols in the table call attention to the few events that are most relevant to the most common use case: CI/CD.
Webhook | Scope | Possible Action Values | Event Type(s) Emitted |
---|---|---|---|
check_run |
specific commit |
|
|
check_suite |
specific commit |
|
|
create |
specific branch or tag |
|
|
deleted |
specific branch or tag |
|
|
fork |
specific repository |
|
|
gollum |
specific repository |
|
|
installation |
multiple specific repositories; the gateway will split this into multiple repository-specific events |
|
|
installation_repositories |
multiple specific repositories; the gateway will split this into multiple repository-specific events |
|
|
issue_comment |
specific repository |
|
|
issues |
specific repository |
|
|
label |
specific repository |
|
|
member |
specific repository |
|
|
milestone |
specific repository |
|
|
page_build |
specific repository |
|
|
project_card |
specific repository |
|
|
project_column |
specific repository |
|
|
project |
specific repository |
|
|
public |
specific repository |
|
|
pull_request |
specific commit |
|
|
pull_request_review |
specific commit |
|
|
pull_request_review_comment |
specific commit |
|
|
push |
specific commit |
|
|
release |
specific repository |
|
|
repository |
specific repository |
|
|
status |
specific commit |
|
|
team_add |
specific repository |
|
|
watch |
specific repository |
|
|