Your application can use webhooks to subscribe to events happening on your Aviator account.
When configuring a webhook, you can use the UI to choose which event actions will send you payloads. Only subscribing to the specific events you plan on handling limits the number of HTTP requests to your server. You can also subscribe to all current and future event actions. You can change the list of subscribed events anytime.
Each event corresponds to a certain set of actions that can happen on your organization’s repository. For example, if you subscribe to the merge failure event you'll receive detailed payloads every time a PR fails to merge.
Each webhook event payload also contains properties unique to the event. Most of the common properties are listed below.
All webhook payloads contain an action property that contains the specific activity that triggered the event.
Name of Github repository associated with the action.
Name of the Github organization associated with the action.
Integer. PR Number associated with the action.
Github handle of the author of the PR.
Current status of the PR. Valid options: open, pending, queued, blocked, merged
Boolean. Represents whether the skip line label is present for the PR.
Represents the reason for failure, if there was a failure. See Status Codessection for all possible options.
Optional. Present if there is an additional message provided by Github on the reason for failure.
Optional. List. List of CI names that failed in case of CI failure.
Below is the list of actions that can be configured in the MQ UI to receive webhook events.
When it is triggered
When the PR is opened.
When the Aviator trigger label was added to a PR.
When the PR is queued. This typically happens when the PR is in an approved state and the Aviator trigger label is associated with the PR.
When the Aviator label is manually removed from the PR. It is not reported in case of PR failing to merge.
When the PR reaches the top of the queue for processing.
When the PR is successfully merged.
When the PR fails to merge and is blocked. The typical reason for failures can be retrieved from status_code, including CI failure or merge conflict.
(Parallel mode only) When a PR is stuck if the original PR is still running the checks after the specified timeout.
(Parallel mode only) When a parallel PR queue is reset.