This page describes the behaviour of the DevSensei app in details.
(The content of this table page only apply to if you enabled full Ship/Show/Ask support. Please refer to the Getting started - DC page to enable it.)
Ship/Show/Ask behaviour summary
All pull requests are characterised by DevSensei in 5 different categories. The behaviour of these categories is summurised in the table below.
Auto-merge ? | Number of require approvals | |
|---|---|---|
No Ship/Show/Ask | No | 0 |
Ask>=n | No | n |
Show | Yes | 0 |
Show>=n | Yes | n |
Ship | Yes | 0 (And Skip Code Owners) |
Ask pull requests
When an [Ask>=n] pull request is initiated, it will not be merged automatically. Moreover, a merge check requiring n approvals is added to the pull request. This means that in order for the pull request to be successfully merged, it must receive n approvals from designated reviewers or team members.
...
You can configure Pull Requests to be merged automatically, optionally requiring a certain number of approvals.
[Show>=n] pull requests will be automatically merged as soon as they receive n approvals. In addition, all other merge checks (such as passing tests, code reviewno open tasks, etc.) must also be fulfilled for the pull request to be merged. This feature is useful for ensuring that a certain level of quality and review is met before code is merged into the main branch.
...
To initialte a [Ship] pull request, the user must select Auto-Merge, they should not require any approvals and they must select Merge without reviewers.
...
FAQ
How do DevSensei and Code Owners interact?
For the most part, DevSensei and Code Owners are two independent features next to each other. The only exception is the interaction regarding [Ship] pull requests.
In particular:
a [Show] pull request doesn’t require any approvals to be merged. However, if Code Owners requires approvals for that same pull request, they will not be skipped. Therefore the pull request will not be automatically merged before Code Owners merge checks are fullfilled
a [Show>=2] pull request will require two approvals, regardless of who they are coming from. If for its part, Code Owners requires 3 approvals as merge check, then in total only 3 approvals will be necessary. The same applies for [Ask>=2], the difference being that Ask does not auto-merge
a [Ship] pull request will skip assignment of Code Owners. This is inline with the philosophy of Ship/Show/Ask: Ship pull request are meant for tiny and trivial changes to your repository.
I accidentally create a pull request in the wrong category, can I do something about it?
DevSensei uses the title of a pull request to determine its category. For example a [Show>=2] pull request will have its title start with [SHOW>=2]. If you modify the title of the pull request after it has been created, it will also change its category for DevSensei.
When does DevSensei check if a pull request must be auto-merged?
DevSensei will check that a pull request can be auto-merged everytime an impactful change happens to the pull request. For example, a new task compleated, a new approval, a finished built or a change in the title. However, it will never do so less than 20 seconds after the creation of the pull request, leaving you a time window to change the pull request title if you accidentally used the wrong one (see “I accidentally create a pull request in the wrong category, can I do something about it?”).
Is there a way to make some kind of “work in progress” pull request?
Perhaps you want to use auto-merging pull requests, but your pull request is not actually ready and you don’t want it to be auto-merged right away. If that is the case, you have two options:
after creating the pull request, create an open task to prevent the merge (note that if that is the only merge check on your repository, you only have 20 seconds to do so (see “When does DevSensei check if a pull request must be auto-merged?”)
you can create the pull request selecting “Manual merge”, and change the title to [SHOW>=n] (with n replaced with the desired number) when it is not longer work in progress.