Git
Definition
Scope shared by the GitLab trigger kinds.
A GitLab webhook is registered by the customer on a group, and each Dash0 GitLab integration is anchored to one instance — so unlike the GitHub App, Dash0 cannot declare which events it receives. Which of these triggers ever fire depends on the event checkboxes ticked when the webhook was created.
Optional list of merge request actions to filter on: open, close, reopen,
update, merge, approved, unapproved.
Only gitlab.merge_request uses this; a note carries no action, so the filter is
skipped for gitlab.note rather than blocking every event.
Optional list of GitLab instance hosts to filter on, e.g. gitlab.com,
gitlab.acme.io. Omit to match every instance the organization has connected.
Only worth setting when an organization has more than one GitLab integration: a group or
project path is unique within an instance but not across instances, so acme/backend on
gitlab.com and on a self-managed host are different groups that a path filter alone
cannot tell apart.
Optional list of group full paths to filter on, e.g. acme/backend. A group covers every
project beneath it at any depth, so acme/backend matches acme/backend/api and
acme/backend/tools/lint, but not acme/frontend/web — nor acme/backend-legacy/api,
which is a different group.
A group given as a numeric id rather than a path matches nothing: ids and paths cannot be compared, and a filter that quietly matched everything would be worse than one that visibly matches nothing.
Explicitly match every group on the instance. Required to be set when no groups and
no projects are given, so that a match-everything trigger is always a deliberate
choice rather than an omission — mirroring allOrganizations on GitHub.
Optional list of project full paths to filter on, e.g. acme/backend/api.
Explicitly match every project on the instance. See allGroups.
Used by 2
These schemas and endpoints reference this type directly.