Project integrations
DETAILS: Tier: Free, Premium, Ultimate Offering: SaaS, self-managed
NOTE: This page contains user documentation for project integrations. For administrator documentation, see Project integration administration.
You can integrate with external applications to add functionality to GitLab.
You can view and manage integrations at the:
- Instance level (self-managed GitLab)
- Group level
You can use:
- Instance-level or group-level default settings for a project integration
- Custom settings for a project or group integration
Manage group-level default settings for a project integration
Prerequisites:
- You must have at least the Maintainer role for the group.
To manage group-level default settings for a project integration:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > Integrations.
- Select an integration.
- Complete the fields.
- Select Save changes.
WARNING: This may affect all or most of the subgroups and projects belonging to the group. Review the details below.
If this is the first time you are setting up group-level settings for an integration:
- The integration is enabled for all subgroups and projects belonging to the group that don't already have this integration configured, if you have the Enable integration toggle turned on in the group-level settings.
- Subgroups and projects that already have the integration configured are not affected, but can choose to use the inherited settings at any time.
When you make further changes to the group defaults:
- They are immediately applied to all subgroups and projects belonging to the group that have the integration set to use default settings.
- They are immediately applied to newer subgroups and projects, even those created after you last saved defaults for the integration. If your group-level default setting has the Enable integration toggle turned on, the integration is automatically enabled for all such subgroups and projects.
- Subgroups and projects with custom settings selected for the integration are not immediately affected and may choose to use the latest defaults at any time.
If instance-level settings have also been configured for the same integration, projects in the group inherit settings from the group.
Only the entire settings for an integration can be inherited. Per-field inheritance is proposed in epic 2137.
Remove a group-level default setting
Prerequisites:
- You must have at least the Maintainer role for the group.
To remove a group-level default setting:
- On the left sidebar, select Search or go to and find your group.
- Select Settings > Integrations.
- Select an integration.
- Select Reset and confirm.
Resetting a group-level default setting removes integrations that use default settings and belong to a project or subgroup of the group.
Use instance-level or group-level default settings for a project integration
Prerequisites:
- You must have at least the Maintainer role for the project.
To use instance-level or group-level default settings for a project integration:
- On the left sidebar, select Search or go to and find your project.
- Select Settings > Integrations.
- Select an integration.
- On the right, from the dropdown list, select Use default settings.
- Under Enable integration, ensure the Active checkbox is selected.
- Complete the fields.
- Select Save changes.
Use custom settings for a project or group integration
Prerequisites:
- You must have at least the Maintainer role for the project or group.
To use custom settings for a project or group integration:
- On the left sidebar, select Search or go to and find your project or group.
- Select Settings > Integrations.
- Select an integration.
- On the right, from the dropdown list, select Use custom settings.
- Under Enable integration, ensure the Active checkbox is selected.
- Complete the fields.
- Select Save changes.
Available integrations
Integration | Description | Integration hooks |
---|---|---|
Asana | Add commit messages as comments to Asana tasks. | {dotted-circle} No |
Assembla | Manage projects with Assembla. | {dotted-circle} No |
Atlassian Bamboo | Run CI/CD pipelines with Atlassian Bamboo. | {check-circle} Yes |
Bugzilla | Use Bugzilla as an issue tracker. | {dotted-circle} No |
Buildkite | Run CI/CD pipelines with Buildkite. | {check-circle} Yes |
Campfire | Connect Campfire to chat. | {dotted-circle} No |
ClickUp | Use ClickUp as an issue tracker. | {dotted-circle} No |
Confluence Workspace | Use Confluence Workspace as an internal wiki. | {dotted-circle} No |
Custom issue tracker | Use a custom issue tracker. | {dotted-circle} No |
Datadog | Trace your GitLab pipelines with Datadog. | {check-circle} Yes |
Discord Notifications | Send notifications about project events to a Discord channel. | {dotted-circle} No |
Drone | Run CI/CD pipelines with Drone. | {check-circle} Yes |
Emails on push | Send commits and diffs on push by email. | {dotted-circle} No |
Engineering Workflow Management (EWM) | Use EWM as an issue tracker. | {dotted-circle} No |
External wiki | Link an external wiki. | {dotted-circle} No |
GitGuardian | Reject commits based on GitGuardian policies. | {dotted-circle} No |
GitHub | Receive statuses for commits and pull requests. | {dotted-circle} No |
GitLab for Slack app | Use the native Slack app to receive notifications and run commands. | {dotted-circle} No |
Google Chat | Send notifications from your GitLab project to a room in Google Chat. | {dotted-circle} No |
Harbor | Use Harbor as the container registry for GitLab. | {dotted-circle} No |
irker (IRC gateway) | Send IRC messages. | {dotted-circle} No |
Jenkins | Run CI/CD pipelines with Jenkins. | {check-circle} Yes |
JetBrains TeamCity | Run CI/CD pipelines with TeamCity. | {check-circle} Yes |
Jira | Use Jira as an issue tracker. | {dotted-circle} No |
Mattermost notifications | Send notifications about project events to Mattermost channels. | {dotted-circle} No |
Mattermost slash commands | Run slash commands from a Mattermost chat environment. | {dotted-circle} No |
Microsoft Teams notifications | Receive event notifications in Microsoft Teams. | {dotted-circle} No |
Packagist | Update your PHP dependencies in Packagist. | {check-circle} Yes |
Pipeline status emails | Send the pipeline status to a list of recipients by email. | {dotted-circle} No |
Pivotal Tracker | Add commit messages as comments to Pivotal Tracker stories. | {dotted-circle} No |
Pumble | Send event notifications to a Pumble channel. | {dotted-circle} No |
Pushover | Get real-time notifications on your device. | {dotted-circle} No |
Redmine | Use Redmine as an issue tracker. | {dotted-circle} No |
Slack slash commands | Run slash commands from a Slack chat environment. | {dotted-circle} No |
Squash TM | Update Squash TM requirements when GitLab issues are modified. | {check-circle} Yes |
Telegram | Send notifications about project events to Telegram. | {dotted-circle} No |
Unify Circuit | Send notifications about project events to Unify Circuit. | {dotted-circle} No |
Webex Teams | Receive event notifications in Webex Teams. | {dotted-circle} No |
YouTrack | Use YouTrack as an issue tracker. | {dotted-circle} No |
Project webhooks
Some integrations use webhooks for external applications.
You can configure a project webhook to listen for specific events like pushes, issues, or merge requests. When the webhook is triggered, GitLab sends a POST request with data to a specified webhook URL.
For a list of integrations that use webhooks, see Available integrations.
Push hook limit
If a single push includes changes to more than three branches or tags, integrations
supported by push_hooks
and tag_push_hooks
events are not executed.
To change the number of supported branches or tags, configure the
push_event_hooks_limit
setting.
SSL verification
By default, the SSL certificate for outgoing HTTP requests is verified based on an internal list of certificate authorities. The SSL certificate cannot be self-signed.
You can disable SSL verification when you configure webhooks and some integrations.