Enforced Pull Request Workflows
Introduction
To get the idea how to work with pull requests in general, check out the related post. This showcase here will demonstrate you how you can use pull requests to enforce your workflows and protect your repositories from unauthorized merges.
How to Prevent Errors
In development teams you will meet all different types of personalities. There are some that will check everything twice before pressing a button, and others that want to start the release job before they have checked the latest changes. While both extremes taken separately can be dangerous, a good team may be able to take advantage from both of them. Nonetheless, sometimes it’s better to make some safeguards. The Review Plugin in SCM-Manager has some mechanisms, to prevent merges of potentially harmful features.
While doing so, it also offers enough flexibility, to prevent starvation due to too harsh requirements.
The Workflow Engine
When you have installed the Review Plugin, you will find a new configuration sub-menu “Workflow Engine” in the global administration settings as well as in the repository settings. Once you activate this engine, you can configure rules that have to be fulfilled, before you can merge a pull request. Some rules will depend on other plugins.
These are the rules, that you can configure (maybe there are more at the time you read this):
- All tasks done: This simple rule makes sure, that all tasks created for the pull request are marked as “done”, so that none is missed in the daily routine.
- Number of approvals: If you have an important repository where four eyes is not sufficient, you can make sure that at least three people took a look at a change, first.
-
All reviewers approved: If you chose the reviewers with great deliberation, it would be good to
ensure, that every one took a look before the merge takes place. -
All CI status successful, All CI status of type successful, Named CI status successful,
Number of CI status successful: If you have one or more continuous integration processes running, it makes sense to ensure, that there are no failures for a pull request. With these options you have the possibility to prevent merges with severe problems.
However sensible your rules may be, some day the time may come where someone has to switch on the siren to speed across the red lights to prevent greater damage. In SCM-Manager we call this an “emergency merge”. This enables developers (with the according permission) to merge pull requests although some rules may not be fulfilled. Your team will know how to handle this wisely.
Examples
You can take a look at a demo repository with a simple workflow configuration and pull requests with different accordance:
-
A not yet fully approved pull request,
where only one of the required reviewers approved the rule, that every reviewer has to give his or her approval. This repository cannot be merged normally, yet.
-
A fully approved pull request,
where both reviewers approved and therefore fulfilled the rule, that every reviewer has to give his or her approval. This pull request can now be merged without further issues. To get more details on the rules, you can click the corresponding line with the green check icon to see this modal.
-
An “emergency merged” pull request,
that had been merged although the required Jenkins build did not succeed. You can see the markings that make this reproducible.
If you need more rules for your workflows or have some questions regarding the current rules, feel free to ask right below this topic.