gitlab-slack is a service that receives outgoing webhook notifications from GitLab and posts information to an incoming webhook on Slack.
- Processes GitLab webhook messages for commits, branches, tags, issues, merge requests and wiki pages. (more info)
- Provides translation from Markdown to Slack's formatting syntax for the formatting features that Slack supports. (more info)
- Issues or merge requests mentioned anywhere in the commit message are aggregated and provided as links to the right of the commit summary line. (more info)
- Changes to tracked labels on issues are notified as issue updates with a summary of label changes as attachments. (more info)
- Status and error messages are logged to
stderr
; if the terminal supports colors, they are output for improved readability. (more info)
- GitLab API Token
The GitLab API token must have administrative privileges to be able to search for users by email address. This is used to translate the commit author email address into a username. - GitLab and GitLab API Version
The GitLab API interactions were written for v4 of their API against GitLab version 11.x. Older or newer versions may work, but are unsupported. - Node.js and NPM Version
The code is written targeting Node.js 8.x LTS and NPM 6.x. Older or newer versions may work, but are unsupported.
gitlab-slack is configured by values in the config.js
file in the application directory. This file is ingested as a Node.js module and has the following structure:
module.exports = {
port: 4646,
slackWebhookUrl: '',
gitLab: {
baseUrl: '',
apiToken: '',
projects: [
{
id: 0,
name: '',
channel: '',
labels: []
}
]
}
};
port
- The port on which to listen. (Default =4646
)slackWebhookUrl
- The URL of the Slack incoming webhook. (Example ='https://hooks.slack.com/services/...'
)gitLab
- The GitLab configuration.baseUrl
- The protocol/host/port of the GitLab installation. (Example ='https://gitlab.company.com'
)
This is expected NOT to have a trailing slash.apiToken
- The API token with which to query GitLab. (Example ='hxg1qaDqX8xVELvMefPr'
)projects
- The project configuration. This section defines which projects should be tracked.id
- The ID of the project.name
- The name of the project. This value is only used for logging; the group/name namespace is recommended. (Example ='group/project-name'
)channel
- Optional. Overrides the default channel for the Slack webhook. (Example ='#project-name'
)
The#
prefix is added if it is not present.labels
- Optional. An array of regular expressions or strings (that will be turned into case-insensitive regular expressions) used to select issue labels that should be tracked for changes. (Example =[ '^Status:', /^Size:/ ]
)
NOTE: If the service receives a message for a project that is not configured (or does not have a channel defined), its notifications will go to the default channel for the incoming webhook.
gitlab-slack improves upon GitLab's built-in Slack integration with attractive notification formatting that provides more detail and functionality while cutting the fat and remaining as concise as possible.
Commit notifications include the repository path and branch, the username of the user who pushed the commit as a link and
a list of commits included in the push. Each commit includes the username of the user who made it, a short-form commit hash
as a link, the first line of the commit message, and a summary of all mentions in the commit message. (more info)
Tag and branch notifications include the repository path, the username of the user who pushed them as a link and the branch or
tag name as a link.
If any commits are included in the new-branch message, they are also notified. If a tag includes a message, it is included below the tag.
Issue notifications include the repository path, the username of the user who performed the issue action, the username of the user to
whom the issue is assigned, the milestone to which the issue is assigned and the username of the user who created the issue.
Milestones and usernames are formatted as a links. Issue notifications include a main attachment that includes the title of the issue,
and, depending on the kind of action, also the issue description. Additional attachments will be included for changes
to tracked labels. (more info
Merge request notifications include the repository path, the username of the user who performed the merge request action, the username
of the user to whom the merge request is assigned, the source branch and the target branch. Usernames and branches are formatted as links.
Merge request notifications include an attachment that includes the title of the merge request and, depending on the kind of action,
also the first line of its description.
Wiki page notifications include the repository path, the username of the user who performed the wiki page action and the slug of
the affected wiki page as a link to that page.
As commit messages are truncated to their first line for notification, any issues or merge requests mentioned elsewhere in the message are de-duplicated and summarized as links at the end of the notified commit message. The following two commit messages...
Removes the fun file (#8, !6)
* Fixes an issue where there was a fun file.
Adds a fun file.
* This is more description.
* Fixes an issue with not having a fun file. (#3, #6, !6)
* Fixes another issue. (#3, !6)
* This line only mentions a merge request. (!5)
...produce the following notification:
When the mention was in the first line, the original mention is removed to avoid duplication.
The following Markdown structures will be translated to a Slack-formatting analogue:
- Bold
- Italic
- Links (files and images)
- Headings
- Bulleted Lists (up to two levels deep)
An issue titled Markdown to Slack formatting is awesome with the following following markdown in the description...
# Heading H1
* Something is _italic_ or *italic*.
* Something else is __bold__ or **bold**.
* Here's a link to [Google](https://google.com).
Here's an [uploaded_file.7z](https://example.com/uploaded_file.7z).
Do you like pictures?
![rubbercheeseburger.jpg](/rubbercheeseburger.jpg)
## **Heading H2**
* A list with...
* ...more than one level!
* Back to the base level.
...produces an issue notification similiar to the following...
Headings are simply bolded; those that are already bolded are handled appropriately. Images are processed into simple links; they do not include the base host/protocol/port of the GitLab instance, so that is added.
For configured projects, label change tracking can be enabled by providing a list of regular expressions or strings (which will be converted to case-insensitive regular expressions) defining which labels gitlab-slack should be interested in. When enabled, label changes will be notified in additional attachments following the main summary attachment. Each label attachment will follow the label's configured color and indicate whether the label was Added or Removed.
The debug module is used for logging under the prefix gitlab-slack
. The logging is split
into the following components:
Component | Description |
---|---|
app |
The main application responsible for the start-up and shut-down process. |
server |
The HTTP server that handles incoming webhook requests. |
api |
The wrapper that handles communication with the GitLab API. |
slack |
The wrapper that handles sending notifications to the Slack incoming webhook. |
handler |
A set of components that handle incoming messages of various types. Sub-components are logged as gitlab-slack:handler:<sub> .Sub-Components: commit , branch , tag , issue , mergerequest , wikipage |
To turn on or off logging of components, assign the DEBUG
environment variable. For example, to only show handler log messages, set
DEBUG
to gitlab-slack:handler:*
. Read the documentation for debug for more information.
nodejs and npm are prerequisites to the installation of this application.
The /scripts directory contains some example service definitions scripts for various init flavors. Check the README files in those directories for more information about each script.
The Master or Owner permission level is required to modify webhooks in GitLab.
- From the project home, click Settings.
- Click Integrations.
- Enter
http://127.0.0.1:PORT
into the URL field if, for example, gitlab-slack is running on the same server as GitLab.
Use the value of theport
key from theconfig.js
file in place ofPORT
.- If gitlab-slack is running on another server, enter the appropriate DNS or URI.
- Check the Push events, Tag push events Issues events, Merge Request events and Wiki Page events triggers. If
desired, check the Confidential Issues events trigger as well.
The other Trigger options are not supported and will result in an "unrecognized" message being sent to the default Slack channel for the webhook. - Depending on your configuration you may want to check or un-check Enable SSL verification.
- The Secret Token feature is not supported.
- Click Add webhook.
Once added, the webhook can be tested using the Test button to the right of the webhook under Webhooks.