GitLab Events
The built-in GitLab Events trigger initiates a flow when it receives a signal from a GitLab webhook.
Add the GitLab Events trigger to the canvas
- Go to the Triggers panel in the palette, expand the App Triggers section and drag the trigger onto the canvas.
- Double-click the trigger (or click the pencil icon).
- Set the authenticating user, and then copy the URL — you'll use this to set up the webhook in GitLab. Alternatively, you can create an integration user to use as the authenticating user.
- Click the Flood Control tab to edit the trigger's default flood control settings. For more information about these settings, see Trigger Flood Control.
- Click Done.
- On the flow canvas, connect the steps you want to run when xMatters receives a request to that URL.
You're now ready to configure GitLab to target the trigger.
Configure GitLab to send requests to the trigger URL
To have GitLab send alerts to the flow trigger, you need to configure a webhook and set it to use the trigger URL.
Configure the webhook
- In GitLab, go to Settings > Webhooks.
- On the Webhooks page fill in the following fields:
- URL: Paste the trigger URL you copied from Flow Designer.
- Add the target names of any recipients you want to notify when the alert fires to the end of the URL.
- For URL authentication, use an ampersand to attach recipients. For example, if you want to notify Emma Pearson and the on-call members in the group responsible for the Antares service, you'd add &recipients=epearson,antares to the URL.
- For other authentication types, use a question mark to attach recipients. For example, if you want to notify Barry Gull and the on-call members in the group responsible for the Cassiopeia service, you'd add ?recipients=bgull,cassiopeia to the URL.
- You must URL-encode any special characters or spaces in the target names.
- Select the type of GitLab events that will send changes to xMatters. The following event types are supported:
- Push events
- Merge request events
- Job events
- Pipeline events
- Deployment events
- Feature flag events
- Releases events
- Leave Enable SSL verification selected.
- Click Add webhook.
You're ready to use the webhook to trigger automated flows, including steps such as sending alerts and initiating incidents, though we always recommend testing before putting things into use.
Outputs
GitLab Events trigger outputs
The trigger has the following outputs you can use as inputs to steps further along the flow.
Label |
Description |
---|---|
Recipients |
List of targeted recipients. Recipients are set by adding a recipients query parameter to the trigger URL. |
Build Stage | Current stage of the job build or pipeline. |
Change Type | Type of change taking place in GitLab. |
Description | Detailed description of the change. |
Object Kind |
GitLab webhook event object kind. Supported values are:
|
Project Link | Direct link to the GitLab project. |
Project Name | Name of the GitLab project that triggered the webhook event. |
Public ID | Public ID of the webhook event, as provided by GitLab. |
Reference Location | Location where the webhook event occurred. |
Status | Status of the current merge request, release, deployment, job, pipeline, and feature flag where the webhook event occurred. |
Timestamp | Timestamp of when the webhook event occurred. |
Title | Title of the webhook event as provided by GitLab. |
Username | Username of the user associated with the webhook event. |
URL | URL of the webhook event. |
Raw Request | JSON representation of the request. You can parse the raw request if you need additional details beyond the standard outputs. |