Getting Started with ChatOps

⚠️ The examples in this chapter work only with serverless Jenkins X.

The role of Git in Jenkins X

Jenkins X’s 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 to our clusters. That logic is the cornerstone of Jenkins X, and has 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.

We might need to assign a pull request to someone for review. That someone might have to review the changes and might need to run some manual tests if they are not fully automated. A pull request could need additional changes, and the committer might need to be notified of that. Someone might need to approve and merge a pull request or choose to cancel it altogether. The list of the actions that we might have to perform once a pull request is created can be quite extensive, and many of them do not result in changes to source code. The period starting with the creation of a pull request until it is merged to the master is filled with communication, rather than changes to the project in question. As such, we need an effective way to facilitate that communication.

Communication driven actions

The communication and decision making that surrounds a pull request needs to be recorded. We need to be able to track who said what and who made what decision. Otherwise, we would not be able to capture the events that lead to a merge of a pull request to the master branch. We’d be running blind. That means that verbal communication must be discarded since it would not be recorded.

Given that such communication should be closely related to the pull request, we can discard emails and wiki pages as well, thus leading us back to Git. Almost every Git platform has a mechanism to create comments tied to pull requests. We can certainly use those comments to record the communication. But, communication by itself is useless if it does not result in concrete actions.

If we do need to document the communication surrounding a pull request, it would be a waste of effort to have to perform related actions separately. Ideally, communication should result in actions.

• When we write a comment that a pull request should be assigned to a reviewer, it should trigger an action that will do the actual assignment and notify that person that there is a pending action.
• If we comment that a pull request should be labeled as “urgent”, that comment should add the label.
• If a reviewer writes that a pull request should be canceled, that comment should close the pull request.
• Similarly, if a person with sufficient permissions comments that the pull request is approved, it should be merged automatically.

RBAC (Role-Based Authentication)

There are a couple of concepts that need to be tied together for our process surrounding pull requests to be effective. We need to be able to communicate, and we already have comments for that. People with sufficient privileges need to be able to perform specific actions (e.g., merge a pull request). Git platforms already implement some form of RBAC (Role-Based Authentication), so that part is already solved.

Furthermore, we need to be notified that there is a pending action we should perform as well as the fact that a significant milestone has been reached. This is solved as well. Every Git flavor provides a notification mechanism. What we’re missing is a process that will tie it all together by executing actions based on our comments.

📝 We should be able to implement ChatOps principles if we manage to convert comments into actions controlled by RBAC and if we receive notifications when there is a pending task.