Bitbucket Cloud · Data Center · Pull request builds · October 26, 2026

Bitbucket pull request builds: build statuses and the merge checks that wait for them

A build server (Bitbucket Pipelines, Bamboo, Jenkins or any other) reports a build status on a commit, and a pull request shows the statuses of its commits. Merge checks can then wait for them. Below is how it works in Bitbucket Cloud and Bitbucket Data Center, from Atlassian's Check build status in a pull request, Suggest or require checks before a merge, Data Center's View builds information and Checks for merging pull requests, and the Cloud and Data Center REST references.

Bitbucket Cloud

• Where builds show: the pull request's Commits tab has a Builds column with the statuses of each commit, and the Builds panel in the right sidebar links to each build. A commit reads Passed when all its builds passed, In progress when none failed and at least one is running, and Failed when at least one failed.
• Reporting a status: POST /2.0/repositories/{workspace}/{repo_slug}/commit/{commit}/statuses/build with key and state, and optionally url, name, description and refname. The states are SUCCESSFUL, FAILED, INPROGRESS and STOPPED. A status with a key the commit already has overwrites the old one; PUT …/statuses/build/{key} changes the state, name, description, URL or ref name, but not the key. The API has no call to delete a status: to replace a failed one, report the same key again.
• Reading them: GET …/pullrequests/{id}/statuses lists a pull request's statuses and GET …/commit/{commit}/statuses a commit's. When we read public repositories on October 26, 2026, the pull request's list held only the statuses of its latest commit.
• The merge check: Minimum number of successful builds for the last commit with no failed builds and no in progress builds. The merge checklist then says At least {#} successful builds on last commit or No failed builds on last commit. It counts every status on the last commit of the source branch, so one failed status fails it even after a later run of the same build passed, unless the runs report the same key (Atlassian's article). Like every merge check, it stops the merge only on Premium with Prevent a merge with unresolved merge checks; otherwise it warns.
• [skip ci]: a commit whose message says [skip ci] gets no build, so the check stays unsatisfied; Atlassian's workaround reports a successful status on that commit through the API (Allow merge checks to succeed when [skip ci] build is present).
• Merging when builds pass: the merge check Allow automatic merge when builds pass lets you press Merge while a build runs; see auto-merge.

Bitbucket Data Center

• Where builds show: once Bitbucket is linked with a build server, a pull request's Overview tab shows the latest build status and its Builds tab the builds of each commit, with log and artifact links. The Builds page lists the builds of the whole instance, filtered by branch or commit.
• Acting on builds: with Bamboo or Jenkins, you can act on builds from the Builds page and the pull request's Builds tab after authorizing Bitbucket once; which actions you get depends on the build server and your access (Perform build actions).
• Reporting a status: POST /rest/api/latest/projects/{projectKey}/repos/{repositorySlug}/commits/{commitId}/builds (since 7.14, with read access to the repository) takes key, state and url, and optionally name, description, parent, ref, buildNumber, duration and testResults. The states are SUCCESSFUL, FAILED, INPROGRESS, CANCELLED and UNKNOWN. The older /rest/build-status/latest/commits/{commitId} is deprecated since 7.14 and takes only the first three. DELETE on the same address with ?key= removes a status, for repository admins.
• Minimum successful builds: a built-in merge check that requires at least the number of successful builds you set before merging.
• Required builds: under Repository settings → Required builds, the build keys that must pass, for pull requests into the target branches you choose (any branch, a branch name, a pattern or the branching model), with source branches you can exempt, such as hotfix-*. It needs a Data Center license and Bamboo 7.1 or later, or the Bitbucket integration plugin 2.0.0 or later. The key depends on the build server: in Bamboo the project key and plan key (PROJ-COREBUILDS), in Jenkins the names on the path to the job, separated by slashes. Through REST: /rest/required-builds/latest/projects/{projectKey}/repos/{repositorySlug}/condition (repository admins), with buildParentKeys, refMatcher and exemptRefMatcher.

Builds in IntelliJ IDEA

Pull Request Inbox for Bitbucket, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the Bitbucket Cloud and Bitbucket Data Center pull requests waiting for your review in an IDE tool window. Under Builds it shows the build statuses of the pull request's latest commit, each as passed, failed, running or stopped with a link to the build, next to the merge checks in plain words, such as "1 of 2 successful builds" (on Data Center, in the server's own words). The review inbox, diffs, merge checks and builds are free; approving, commenting and merging are Pro (US$1.50 a month, with a 30-day trial).

Get it on JetBrains Marketplace

If those builds run on Jenkins: Lesstep also makes Pipeline Inbox for Jenkins, a separate plugin that lists your Jenkins builds in the IDE with their Pipeline stages, failed tests and console logs (reading is free; building, stopping and answering input steps are Pro).

Bitbucket, Bamboo and Atlassian are trademarks of Atlassian; Jenkins® is a registered trademark of LF Charities Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by Atlassian, the Jenkins project or JetBrains.

More: Bitbucket merge checks · Bitbucket auto-merge · Request changes and Needs work · draft pull requests · Bitbucket pull request plugins for IntelliJ IDEA, compared · 日本語