GitLab ChatOps
Notes:
-
Introduced in GitLab Ultimate 10.6. Moved to GitLab Core in 11.9.
-
ChatOps is currently in alpha, with some important features missing like access control.
GitLab ChatOps provides a method to interact with CI/CD jobs through chat services like Slack. Many organizations’ discussion, collaboration, and troubleshooting is taking place in chat services these days, and having a method to run CI/CD jobs with output posted back to the channel can significantly augment a team’s workflow.
How it works
GitLab ChatOps is built upon two existing features:
A new run
action has been added to the slash commands, which takes two arguments: a <job name>
to execute and the <job arguments>
. When executed, ChatOps will look up the specified job name and attempt to match it to a corresponding job in .gitlab-ci.yml. If a matching job is found on master
, a pipeline containing just that job is scheduled. Two additional CI/CD variables are passed to the job: CHAT_INPUT
contains any additional arguments, and CHAT_CHANNEL
is set to the name of channel the action was triggered in.
After the job has finished, its output is sent back to Slack provided it has completed within 30 minutes. If a job takes more than 30 minutes to run it must use the Slack API to manually send data back to a channel.
Developer access and above is required to use the run
command. If a job should not be able to be triggered from chat, it can be set to except: [chat]
.
Creating a ChatOps CI job
Since ChatOps is built upon GitLab CI/CD, the job has all the same features and functions available. There a few best practices to consider however when creating ChatOps jobs:
- It is strongly recommended to set
only: [chat]
so the job does not run as part of the standard CI pipeline. - If the job is set to
when: manual
, the pipeline will be created however the job will wait to be started. - It is important to keep in mind that there is limited support for access control. If the user who triggered the slash command is a developer in the project, the job will run. The job itself can utilize existing CI/CD variables like
GITLAB_USER_ID
to perform additional rights validation, however these variables can be overridden.
Controlling the ChatOps reply
For jobs with a single command, its output is automatically sent back to the channel as a reply. For example the chat reply of the following job is simply Hello World.
hello-world:
stage: chatops
only: [chat]
script:
- echo "Hello World."
Jobs that contain multiple commands, or have a before_script
, include additional content in the chat reply. In these cases both the commands and their output are included, with the commands wrapped in ANSI colors codes.
To selectively reply with the output of one command, its output must be bounded by the chat_reply
section. For example, the following job will list the files in the current directory.
ls:
stage: chatops
only: [chat]
script:
- echo "This command will not be shown."
- echo -e "section_start:$( date +%s ):chat_reply\r\033[0K\n$( ls -la )\nsection_end:$( date +%s ):chat_reply\r\033[0K"
GitLab ChatOps icon
Say Hi to our ChatOps bot. You can find and download the official GitLab ChatOps icon here.
Help and feedback
If there's something you don't like about this feature
To propose functionality that GitLab does not yet offer
To further help GitLab in shaping new features
If you didn't find what you were looking for
If you want help with something very specific to your use case, and can use some community support
POST ON GITLAB FORUM
If you have problems setting up or using this feature (depending on your GitLab subscription)
REQUEST SUPPORT
To view all GitLab tiers and features or to upgrade
If you want to try all features available in GitLab.com
If you want to try all features available in GitLab self-managed
If you spot an error or a need for improvement and would like to fix it yourself in a merge request
EDIT THIS PAGE
If you would like to suggest an improvement to this doc