Ship/Show/Ask Rules - DC

This page describes the behaviour of the DevSensei Ship/Show/Ask feature in details. Refer to About Ship/Show/Ask PR workflow for description and motivation of Ship/Show/Ask.

(The content of this page only applies if you enabled full Ship/Show/Ask support on your project or repository. Please refer to the Getting started - DC page to enable it.)

Ship/Show/Ask behavior summary

All pull requests are characterized by DevSensei in 5 different categories. The behaviour of these categories is summarized in the table below.

Ask pull requests

When an [Ask>=n] pull request is initiated, it will not be merged automatically. Moreover, a merge check requiring n (>=1) 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.

This type of pull request is useful when changes to the codebase have the potential to have a significant impact or when there is a high level of uncertainty surrounding a particular change.

To initiate an [Ask>=n] pull request, the user must select Manual merge and ask to require a certain number of approvals via the dedicated drop-down.

Show pull requests

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. However, Code Owners merge checks will be ignored for such pull request. All other merge checks (such as passing tests, no open tasks, etc.) must still be fulfilled for the pull request to be merged.

[Show] pull requests, on the other hand, will not require any approvals before they can be automatically merged. This feature is useful for small changes that do not require a thorough review. Again, Code Owners merge checks will be ignored but all other merge checks must still be fulfilled before the pull request can be merged.

To initiate a [Show] pull request, the user must select Auto-Merge and don’t require any approvals. To initiate a [Show>=n] pull request, the user must select Auto-Merge and must require a certain number of approvals.

Ship pull requests

[Ship] pull requests are similar to [Show] pull requests, with the difference that they do not add the Code Owners as reviewers anymore. That means that no one will be notified about the pull request.

Like [Show] pull requests, [Ship] pull requests will be merged as soon as all other merge checks pass, but they skip Code Owners assignments from Code Owners.

To initiate a [Ship] pull request, the user must select Auto-Merge, they should not require any approvals and they must select Merge without reviewers.

FAQ

What if I want to use the traditional manual merge for my pull request?

You can select “Manual merge” and requiring “No” approval from DevSensei. This will act as if DevSensei does not exist for your pull request.

How do DevSensei and Code Owners interact?

For the most part, DevSensei and Code Owners are two independent features next to each other. However, DevSensei will skip Code Owners merge checks in the event of a [Ship] or [Show] pull request.

In particular:

• a [Show] pull request doesn’t require any approvals to be merged. Moreover, if Code Owners requires approvals for that same pull request, they will be skipped. Therefore the pull request will be automatically merged even if Code Owners merge checks are not fulfilled.

• a [Show>=2] pull request will require two approvals, regardless of who they are coming from. If for its part, the merge checks on your repository are configured to require 3 approvals, then in total only 3 approvals will be necessary. Code Owners merge checks will be skipped.

• The same applies for [Ask>=2], but they the key difference is that the Ask pull request will not skip Code Owners merge checks. The other difference is that it will 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. Such changes will be more effective if you don’t bother other team members to carry them through.

I accidentally created 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 every time an impactful change happens to the pull request. For example, a new task completed, a new approval, a finished build 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 (or delete the pull request) 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 so that it starts with [SHOW>=n] (with n replaced with the desired number) or with [SHOW] when it is not longer work in progress.

I want to use Ship/Show/Ask but I don’t want Ship or Show to skip Code Owners

This is something that is currently not supported. If you would be interested in such a feature, we will be happy to hear from you!