GitLab webhook events - AWS CodeBuild (original) (raw)
You can use webhook filter groups to specify which GitLab webhook events trigger a build. For example, you can specify that a build is only triggered for changes to specific branches.
You can create one or more webhook filter groups to specify which webhook events trigger a build. A build is triggered if any filter group evaluates to true, which occurs when all the filters in the group evaluate to true. When you create a filter group, you specify:
An event
For GitLab, you can choose one or more of the following events: PUSH, PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED, PULL_REQUEST_MERGED, PULL_REQUEST_REOPENED, PULL_REQUEST_CLOSED,RELEASED, and WORKFLOW_JOB_QUEUED.
The webhook's event type is in its header in the X-GitLab-Event field. The following table shows how X-GitLab-Event header values map to the event types. For the Merge Request Hook webhook event, the payload's object_atttributes.action will contain additional information on merge request type.
| X-GitLab-Event Header value | object_atttributes.action | Event type |
|---|---|---|
| Push Hook | N/A | PUSH |
| Merge Request Hook | open | PULL_REQUEST_CREATED |
| Merge Request Hook | update | PULL_REQUEST_UPDATED |
| Merge Request Hook | merge | PULL_REQUEST_MERGED |
| Merge Request Hook | reopen | PULL_REQUEST_REOPENED |
| Merge Request Hook | close | PULL_REQUEST_CLOSED |
| Release Hook | create, update | RELEASED |
| Job Hook | N/A | WORKFLOW_JOB_QUEUED |
For PULL_REQUEST_MERGED, if a pull request is merged with the squash strategy and the pull request branch is closed, the original pull request commit no longer exists. In this case, theCODEBUILD_WEBHOOK_MERGE_COMMIT environment variable contains the identifier of the squashed merge commit.
One or more optional filters
Use a regular expression to specify a filter. For an event to trigger a build, every filter within the group associated with it must evaluate to true.
ACTOR_ACCOUNT_ID (ACTOR_ID in the console)
A webhook event triggers a build when a GitLab account ID matches the regular expression pattern. This value appears in theaccount_id property of the actor object in the webhook filter payload.
HEAD_REF
A webhook event triggers a build when the head reference matches the regular expression pattern (for example,refs/heads/branch-name andrefs/tags/tag-name). A HEAD_REF filter evaluates the Git reference name for the branch or tag. The branch or tag name appears in the name field of thenew object in the push object of the webhook payload. For pull request events, the branch name appears in the name field in the branch object of thesource object in the webhook payload.
BASE_REF
A webhook event triggers a build when the base reference matches the regular expression pattern. A BASE_REF filter works with pull request events only (for example,refs/heads/branch-name). A BASE_REF filter evaluates the Git reference name for the branch. The branch name appears in the name field of thebranch object in the destination object in the webhook payload.
FILE_PATH
A webhook triggers a build when the path of a changed file matches the regular expression pattern.
COMMIT_MESSAGE
A webhook triggers a build when the head commit message matches the regular expression pattern.
WORKFLOW_NAME
A webhook triggers a build when the workflow name matches the regular expression pattern.
Note
You can find the webhook payload in the webhook settings of your GitLab repository.
Topics
- Filter GitLab webhook events (console)
- Filter GitLab webhook events (SDK)
- Filter GitLab webhook events (AWS CloudFormation)
GitLab manual webhooks
Filter GitLab webhook events (console)
Did this page help you? - Yes
Thanks for letting us know we're doing a good job!
If you've got a moment, please tell us what we did right so we can do more of it.
Did this page help you? - No
Thanks for letting us know this page needs work. We're sorry we let you down.
If you've got a moment, please tell us how we can make the documentation better.