How to disable "builds passed" in a merge check?

[Ray Depew]

I want to allow my users to disable the requirement for a "build passed" for individual Pull Requests. How do I do this?

This is for pull requests that involve documentation, not executable code. For these documentation commits, it makes no sense to do a build. A build job takes a lot of time, and ties up resources that someone else on our team could use.

Users will take this action on individual PRs, not on the Branch, Repository, or Project level. I haven't been able to find the appropriate setting on the Pull Request page, or on the Repository Settings page, and I haven't found an answer (yet) in the documentation. Any pointers?

(Product details: Bitbucket Cloud, Premium plan. I am an Admin.)

[Erez Maadani · Accepted solution]

Hey @Ray Depew ,

You can find this setting under "Repository settings" -> "Workflow" -> "Branch restrictions" -> Click on the "Add Branch Restriction" button on the top right corner -> Choose the "Merge Settings" tab in the opened dialog.

Intuitive... ;)

[Ray Depew]

However, this solution requires the user to specify the branch name or the branch type. I'm looking for a setting that will apply to the repository universally, so that users won't have to drill down into the Branch Restrictions every time they create a PR.

[Patrik S]

Hello @Ray Depew ,

Just adding to @Erez Maadani response, I'm afraid it's not possible to bypass the merge check, but a workaround I can think of is to create a pipeline specifically for pull requests that match the documentation/* branch pattern and configure the pipeline script to just has a simple command (such as an echo) so it doesn't take much time. Then you could have your developers always use a branch named documentation/something when they need to update the documentation that does not require the normal build to be run. That pull request should just trigger the simple build which would ideally be completed in a few seconds.

Thank you, @Ray Depew !

Patrik S

[Ray Depew]

@Patrik S that's a good idea for a workaround. Thank you.