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 ...