Merge Check Section

List of enforced checks that protect against merging unless they all succeed.

Let us know if your use case is not covered.

Merge checks reuse the same expressions as conditions, and can be grouped with a custom title. DevSensei also offers alias merge checks for common use cases.

Custom Check

Example

merge-checks:
  - title: block when PR title requests
    check:
      - title ~!= '[block]*'

Properties

Alias: Minimum Approvals

Equivalent to a custom merge check with the single condition count(approved-by) >= n for positive number n.

Example

merge-checks:
  - minimum-approvals: 1

Properties

Alias: Minimum Successful Builds

Equivalent to a custom merge check with the conditions:

• count(builds.successful) >= n for a positive number n.

• count(builds.failed) = 0 disallow failed builds

• count(builds.in-progress) = 0 wait for all builds to be complete

Example

merge-checks:
  - minimum-successful-builds: 1

Properties

Alias: No Open Tasks

Equivalent to a custom merge check with the single condition count(open-tasks) = 0.

Add this merge check by adding the string no-open-tasks to the workflow merge-checks list.

Example

merge-checks:
  - no-open-tasks

Properties

This merge check alias has no property.

Code Owners Merge Check

This merge check enforces rules as described in the Code Owners documentation. For existing CODEOWNERS users, copy your merge checks to this section.

Properties

Example

merge-checks:
- codeowners-check: |
    (Check(@@MyDevs >= 2) | Check(@@JavaExperts >= 1))

Merge Check Use Cases

The merge-checks section gives more control over which pull requests should be merged, for example applying unique checks to specific branch patterns.

merge-checks:
  - title: require no incomplete tasks
    check:
    - count(open-tasks) = 0

merge-checks:
  - title: require a successful build
    check:
    - count(builds.successful) > 1
    - count(builds.in-progress) = 0
    - count(builds.failed) = 0

workflows:
  - name: strict main checks
    conditions:
      - destination = 'main'
    merge-checks:
      - title: 3 approvers on main
        check:
          - count(approved-by) >= 3

merge-checks:
  - title: Follow branch pattern
    check:
      - or:
          - source ~= 'feature/*'
          - source ~= 'release/*'
          - source ~= 'hotfix/*'
          - source = 'main'

workflows:
  - name: strict release checks
    conditions:
      - destination ~= 'release/*'
    merge-checks:
      - title: never release from feature
        check:
          - source ~!= 'feature/*'

workflows:
  - name: strict release author checks
    conditions:
      - destination ~= 'release/*'
    merge-checks:
      - title: enforce PR author
        check:
          - author = 'release-admin'

workflows:
  - name: Formatting checks
    conditions:
    merge-checks:
      - title: enforce text size
        check:
          - title <= 50
          - description <= 10000

workflows:
  - name: Commit message checks
    conditions:
    merge-checks:
    - title: Ensure that Jira key issues is referenced
      check:
        - count(jira-keys) > 0
    - title: Ensure your commit title starts with FIX,FEATURE or MISC
      check:
        - forall(commits.titles, $1~=regex('(FIX|FEATURE|MISC).*'))

workflows:
  - name: Size checks
    conditions:
    merge-checks:
      - title: enforce max changed files
        check:
          - count(changed-files.added) <= 50

merge-checks:
  - title: Not draft or conflicting
    check:
      - not(draft)
      - not(conflicts)

Planned Use Cases

The following ideas rely upon planned or otherwise unimplemented features. Contact support to let us know your use case.

Fine-grained equivalents to built-in Bitbucket merge checks

Supporting the following would allow to create finer grained checks (e.g. by filtering on destination branch pattern):

• Require no "requested changes" status

Support non-functional requirements

• Require that a pull request has been open long enough to be seen (time-based condition)

• Prevent merge to a release branch on a specific day.

More fine-grained attributes

• check text contents of open-tasks, e.g. if your team uses a marker to indicate some tasks can be ignored.

• check specific user in approved-by.

Code Owners merge checks

Over time we hope to migrate the merge checks from the add-codeowners action, starting with the codeowners-check option. We could possibly make them more flexible, for example check the intersection of approved-by with the added code owners.