Jenkins X main logic is based on applying GitOps principles. Every change must be recorded in Git, and only Git is allowed to initiate events that result in changes in our clusters. That logic is the cornerstone of Jenkins X, and it served us well so far. However, there are actions we might need to perform that do not result in changes to the source code or configurations. Hence the emergence of ChatOps.

We can define ChatOps as conversation driven development. Communication is essential for all but single-person teams. We need to communicate with others when the feature we’re developing is ready. We need to ask others to review our changes. We might need to ask for permission to merge to the master branch. The list of the things we might need to communicate is infinite. That does not mean that all communication becomes ChatOps, but rather that parts of our communication does. It’s up to the system to figure out what which parts of communication should result in actions, and what is a pure human-to-human messaging without tangible outcomes.

I won’t bore you with the theory and principles of ChatOps. Instead, we’ll take a look at how Jenkins X implements it.

A Quick Practical Demonstration

We’ll need a Kubernetes cluster with the serverless flavor of Jenkins X. If you don’t have one at hand, feel free to use one of the Gists that follow to create a new cluster or install Jenkins X in an existing one. Bear in mind that the Gists also contain the command that will let you destroy the cluster when you’re finished “playing”.

You will need to install jx first. Please follow the instructions from Get jx if you don’t have it already.

• Create new serverless GKE cluster: gke-jx-serverless.sh
• Create new serverless EKS cluster: eks-jx-serverless.sh
• Create new serverless AKS cluster: aks-jx-serverless.sh
• Use an existing cluster: install-serverless.sh

If in doubt, I recommend GKE (Google Kubernetes Engine) as being the most stable and feature-rich managed Kubernetes solution.

The best way to explore the integration Jenkins X provides between Git, Prow, and the rest of the system is through practical examples. The first thing we’ll need is a project, so we’ll create a new one.

jx create quickstart \
  -l go \
  -p jx-prow \
  -b

cd jx-prow

Since ChatOpts is mostly related to pull requests, we need to define who is allowed to review and who can approve them. We can do that by modifying the OWNERS file generated when we created the project through the Jenkins X quickstart. Since it would be insecure to allow a person who made the PR to change that file, the one that counts is the OWNERS file in the master branch. So, that’s the one we’ll explore and modify.

cat OWNERS

The output is as follows.

approvers:
- vfarcic
reviewers:
- vfarcic

The OWNERS contains the list of users responsible for the codebase of this repository. It is split between approvers and reviewers sections. Such split is useful if we’d like to implement a two-phase code review process in which different people would be in charge of reviewing and approving pull requests. However, more often than not, those two roles are performed by the same people so Jenkins X comes without two-phase review process out of the box (it can be changed though).

To proceed, we need a real GitHub user (other than yours) so please contact a colleague or a friend and ask him to give you a hand. Tell her that you’ll need her help to complete some of the steps of the exercises that follow. Also, let her know that you need to know her GitHub user.

We’ll define two environment variables that will help us create a new version of the OWNERS file. GH_USER will hold your username, while GH_APPROVER will contain the user of the person that will be allowed to review and approve your pull requests. Typically, we would have more than one approver so that the review and approval tasks are distributed across the team. For demo purposes, the two of you should be more than enough.

W> Before executing the commands that follow, please replace the first [...] with your GitHub user and the second with the user of the person that will approve your PR.

GH_USER=[...]

GH_APPROVER=[...]

Now we can create a new version of the OWNERS file. As already discussed, we’ll use the same users as both reviewers and approvers.

echo "approvers:
- $GH_USER
- $GH_APPROVER
reviewers:
- $GH_USER
- $GH_APPROVER
" | tee OWNERS

All that’s left, related to the OWNERS file, is to push the changes to the repository.

git add .

git commit -m "Added an owner"

git push

Even though the OWNERS file defines who can review and approve pull requests, that would be useless if those users are not allowed to collaborate on your project. We need to tell GitHub that your colleague works with you by adding a collaborator (other Git platforms might call it differently).

open "https://github.com/$GH_USER/jx-prow/settings/collaboration"

Please login if you’re asked to do so. Type the user and click the Add collaborator button.

Your colleague should receive an email with an invitation to join the project as a collaborator. Make sure that she accepts the invitation.

I> Not all collaborators must be in the OWNERS file. You might have people who collaborate on your project but are not allowed to review or approve pull requests.

Since most of the ChatOps features apply to pull requests, we need to create one.

git checkout -b chat-ops

echo "ChatOps" | tee README.md

git add .

git commit -m "My first PR with prow"

git push --set-upstream origin chat-ops

We created a new branch chat-ops, we made a silly change to README.md, and we pushed the commit.

Now that we have the branch with the change to the source code, we should create a pull request. We could do that by going to GitHub UI. There is a better way though. jx allows us to do that through the command line. Given that I prefer terminal screen over UIs (and you don’t have a say in that matter), we’ll go with the latter option.

jx create pr \
    -t "PR with prow" \
    --body "What I can say?" \
    -b

We created a pull request and are presented with a confirmation message with a link. Please open it in your favorite browser.

Given that no PR should be approved without a kitten, we’ll add one.

Please type the following PR comment and press the Comment button.

No PR should be without a kitten

/meow

You should see a picture of a cat. We did not really need it, but it was a good demonstration of communication through comments that results in automatically executed actions.

When we created a pull request, it was automatically assigned to one of the approvers. Your colleague should have received a notification email. Please let her know that she should go to the pull request (instructions are in the email), type /lgtm (looks good to me), and click the Comment button.

Please note that /approve and /lgtm have the same purpose in this context. We’re switching from one to another only to show that both result in the pull request being merged to the master branch.

After a while, the PR will be merged, and a build of the pipeline will be executed. That, as you hopefully know, results in a new release being validated and deployed to the staging environment (thanks to Jenkins X pipelines).

You will notice that email notifications are flying back and forth between you and the approver. Not only that we are applying ChatOps principles, but we are at the same time solving the need for notifications that let each involved know what’s going on as well as whether there are pending actions. Those notifications are sent by Git itself as a reaction to specific actions. The way to control who receives which notifications is particular to each Git platform and I hope that you already know how to subscribe, unsubscribe, or modify Git notifications you’re receiving.

As an example, the email sent as the result of approving the PR is as follows.

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vfarciccb

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:
OWNERS [vfarciccb]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

All in all, the pull request is approved. As a result, Prow merged it to the master branch, and that initiated a pipeline build that ended with the deployment of the new release to the staging environment.

Please wait until the All checks have passed message appears in the PR.

That was a very quick overview of ChatOps in Jenkins X. We only scratched the surface. Now it’s up to you to roll up your sleeves and explore everything Prow, Tekton, Jenkins X Pipeline Operator and other tools offered through the serverless Jenkins X bundle.

The DevOps 2.6 Toolkit: Jenkins X

The article you just read is an extract from The DevOps 2.6 Toolkit: Jenkins X.

The book is still in progress, and I do not yet have a clearly defined scope. I write about tech I’m working with and that interests me the most. Right now, that’s Jenkins X.

You can get the book from LeanPub. If you do, you’ll get updates whenever a new chapter is finished. At the same time, you can get more actively involved and send me your comments, suggestions for the next topics, bug reports, and so on. I’d love to hear back from you.