GitLab Next

This issue is intended to formulate an MVC for our first foray into Chatops (https://gitlab.com/gitlab-org/gitlab-ce/issues/34311). We have a pressing need for this internally to help our infrastructure teams (https://gitlab.com/gitlab-com/infrastructure/issues/3556) effectively perform their jobs.

Proposal

MVC

• Chatops commands are defined in the project's .gitlab-ci.yml file. This should be the last stage in the pipeline, and each job should be set to only: chat, so they are not included in other pipelines.
  • Optionally jobs could be set for specifically tagged runners, perhaps co-located in the desired environment and may have special access or credentials present. (i.e. access to vault, IAM role, etc.)
• Utilize existing Slack Chatops integration, and enhance to lookup CI jobs in chatops stage when it encounters any unknown action. Command format /slash_command <job> <options>
• If it finds a CI job that matches, a new pipeline of the matching job on master is executed for the most recent commit/pipeline.
• Job is created and one additional variable is passed: CHATOPS_ARGUMENTS which contains any additional arguments specified.
  • User information is already available in existing variables: GITLAB_USER_ID, GITLAB_USER_EMAIL, GITLAB_USER_LOGIN, and GITLAB_USER_NAME
  • The job can then optionally confirm access rights by the user, as well as parse any passed arguments.
• For the MVC, the Slack chatops command will reply with a link to the created job. (Or in the event no job was found, an error.) This way the user can easily see progress and results.
  • If we have time, the chat_reply section will be returned. If that doesn't exist, we will return the full build script section in Slack.
• Build log is captured and attached to the job, as normal.

To accomplish, I think only two modifications need to be made:

1. Enhancements to the Slack chatops plugin, perhaps forking it to reduce testing surface area and allow for rapid enhancements. (Rip out all existing commands, always look up for CI job. Can call it something else, but still link to Slack.)
2. Add support to CI for triggering a manual job with additional environment variables. We already support passing custom variables for a pipeline (see schedules), we'd just need to allow this for a particular job.

MVC 2

• Job can output any desired messaging for the user, in a file chatops-reply.txt. This can then be set to be persisted as an artifact for the job.
• Slack Chatops integration is then enhanced:
  • Sets a listener for when the job is completed
  • On completion, delivers chatops-response.txt or a message of Job Success or Failure.
• Include CHATOPS_USER and CHATOPS_ARGUMENTS in audit log of CI job.

Backlog

• Change for chatops commands to a full bot, as there are significant limitations with chatops commands on Slack. (Have to complete all responses within 30min, cannot respond with files or images)
• Put chatops commands in own YML, to not pollute CI YML or UI
• Dedicated UI tab for chatops jobs, for cleaner audit log and viewing commands in progress. Also reduce noise in CI pipelines view.
• Proper RBAC/ACL's
• ...