Skip to end of metadata
Go to start of metadata

Plugin Information

View Stash Pullrequest Builder on the plugin site for more information.

This plugin builds pull requests from an Atlassian Stash (Bitbucket Server) instance and will report the test results as comments

Stash Pull Request Builder Plugin

This Jenkins plugin builds pull requests from an Atlassian Stash server (now known as Bitbucket Server) and will report the test results as a comment. This plugin was inspired by the GitHub & BitBucket pull request builder plugins.



Please see the file:


  • Bug fix - post correct links to Jenkins in Stash comments with recent Jenkins versions
  • Added ability to probe Stash for the merge status to make Stash update the refspecs
  • Using repackaged EasySSLProtocolSocketFactory from commons-httpclient
  • Improved field names in the configuration
  • Improved
  • Bug fix - the only build on comment mode does not work after the first comment
  • Added ability to merge on build success
  • Added ability to cancel previously queued and running jobs when the PR is updated
  • Using EnvironmentContributor for variables
  • Only offer valid credentials in the credentials drop down
  • Bug fix - Jenkins issue #30558 - sockets causing problems with hanging triggers
  • Bug fix - include default parameter values in build queue
  • Added project name to log messages
  • Branch name filters can now be regular expressions
  • Support all build states (now all states are reported, not just success or everything else as failure in the build PR comment)
  • Fix PR branch filters
  • Added ability to only keep the most recent PR status comment
  • Logging improvements
  • Ability to limit PR builds to specified target branches only
  • Added credentials support - this is a breaking change, please add a username/password credential for the user you want PR build comments to be posted from. Old builds will fail until you update them with the right credentials from the credentials plugin. 
  • Fixup branch & ref specs in git config - again this is a breaking change and you should update your git configuration (URL, ref spec & branch specifier), please see the updated README  
  • Fix bug with Stash response code handling 
  • Better error handling when Stash returns 200/OK response
  • Added support for custom parameters in the 'test this please' comment
  • Option to ignore SSL certificates (useful if you dont have proper certificates with your Stash instance)
  • Fixes for PR pagination
  • Added build duration to build finished message in PR - useful for tracking runtimes/test overheads added in PRs. 
  • Improved Stash polling
  • Better JSON handling 
  • Added better support for the notify Stash plugin to only tag the source commit SHA1
  • Bugfixes
  • Use Git SCM as provider for hostname and credentials needed for the pull request builder
  • Now it is also possible to verify pull requests from another fork (while previously it would only work in the same repository, or at least with the merge before build feature). Prerequisite is that you add +refs/pull-requests/:refs/remotes/origin/pr/ as refspec.
  • Additionally you can filter on the target branch which makes you able to restrict checking pull requests on a specific (release) branch.
  • Support for global environment variables has been added.
  • Added post build custom comment support
  • Marked credentials plugin as required dependency for upcoming v1.3.0 release with Credentials support
  • Added ability to customise the build phrase (change from the default of 'test this please')
  • Added ability to only have PR built if its merge-able (i..e has been approved)
  • Added ability to only have PR built if its not conflicted
  • Added check to only build PR on comment (don't auto build) based on build phrase (default is 'test this please')
  • Fix bug with passing branch names with a '/'
  • Reduce logging verbosity
  • Initial release


  1. At the moment, each time a new comment is added to the Stash Pull Request, Jenkins is picking it up as a change and re-running the tests.  Is there a configuration that can be updated or set to avoid this?  We only want to re-run the tests if the commit changes.

  2. Is there a way to exclude specific branches by name?

  3. Thanks for the plugin. Just gave it a spin, using it as a trigger to launch another job, which has some complicated default/changeable build params for developers, so it was easier to call it than hack into it.

    A few tricks to note are:

    • I added to that called job's build params a CI_FORK_REPO, CI_FORK_BRANCH and CI_FORK_REFSPEC build param, and referenced them as the git repo, branch and refspec to check out. We actually had the former two in place all over our jobs, inherited when one calls another (mostly we use multiphase in this setup), so developers could run their version of code against "standard conditions" on independent platform (not their workstation) before posting a pull request. The default Repo is one from a selectable list (Extensible list or a Global variable, depending on a job), the branch is a String (defaults to `*master`) and now the refspec is also a string, defaults to empty unless set by this plugin calling that job.
    • I defined a job that does not check out anything by itself, just has the Stash pullrequest builder ticked and fields filled out per article above. As its activity it "Triggers/calls builds on another job" and calls the specified job (and waits for it to finish). Our typical setup adds Build on same node, use same Build parameters (though there are none, at least explicitly, in this stash-poller job), and defines a few parameters for the called job:


      Note to NOT use quoting in these definition of values - those quotes propagate to Git client and upset it (wink) Don't forget the "ssh://" schema part, either.

    • The Stash Host is a base URL, not bare hostname, so don't forget to type in the schema ("http://")
    • The credentials for polling Stash REST API are an account and password (for web-interface); credentials for Git over SSH are a ssh-key added to the profile of that same account on Stash. That account is added to the organizations and developers' repos with a right to read. Note that the SSH key added to a profile can not be explicitly added to a project and vice-versa. If you want to access some projects by a dedicated key - it must be a separate key in SSH and credential in Jenkins.
      • Thinking of it, we might use http:// for repo access too... at least to read them. For some reason we do not. 
        UPDATE: tested that we can, and see also the nits below. The corresponding format would be:


        Note that the project names are "as is" (lowercased), and user names are prefixed with a tilde character. Also note that your stack of called jobs would then have to use the HTTP (not ssh-key) credentials to access the repo over this transport, at least if the repo is not marked as publically accessible (otherwise, it can allow anonymous HTTP cloning). If your Stash admins did not block HTTP cloning (which is possible and some recommend), you can enjoy faster checkouts over HTTP, or so they say - in my few tests it was indeed marginally faster, but not enough to be a game-changer by itself.

    • The Jenkins-cron granularity for 1 minute should be specified as an asterisk; the soft-scheduler syntax with `H/1` is not 1 minute but 1 hour, or documented so per long-standing bug ( and other posts). The `H/2` is indeed around once every two minutes.
    • "test this please" in comments to the PR is indispensable while tinkering with the recipe on Jenkins side, and unchanged code in Git (wink)
    • I also added a Stash notification plugin as a post-job task, so the Stash PR interface has an icon to report the statistics of PR builds happening and passing or not. Ultimately it can be among automated criteria that the PR can be merged.

    • Per JENKINS-35219 - Getting issue details... STATUS  note to mark Build if PR is mergeable in the polling job config. UPDATE: See the post below for alternative solution, if requiring mergeability is too harsh for your practical use-case.

    One thing slightly missing for ease of integration is a prepopulated variable with the hostname (or URL) that should be passed to Git client - having to type in "ssh://", and retype when making jobs for different stashes, is annoying (wink) I posted a bug on this: JENKINS-46605 - Getting issue details... STATUS  (including details of URLs reported back by Stash REST API).

    Another, maybe related to recent security revisions in Jenkins core, is that the job description provided by the plugin (I guess) is posted as verbatim HTML markup of the a-href tag with URL to PR web-interface enclosing the title of the PR. This HTML markup ends up seen in both the Jenkins interface (list of built jobs on the left) and in the notifications posted back to Stash (not the PR comments, but the "X builds failed" summary and the popup that details it).

    • UPDATE: JENKINS-22028 - Getting issue details... STATUS   details about enabling HTML markup in Jenkins Web-GUI, and it works for the job list. The notifications posted back to Stash (not comments) still have the verbatim markup, but that's probably the other plugin's problem.
    1. UPDATE: As an alternative to requiring "Build if PR is mergeable" above (this checkbox indeed avoided testing PRs that were deemed not readily mergeable), or similarly requiring "Build only if Stash reports no conflicts", the issue behind JENKINS-35219 can be worked around by crafting the request ourselves. For this I defined an additional "Execute Shell" step in the PR polling job described above, to be executed before triggering/calling the build on actual job which is the implementation of our test. This new step calls the Stash REST API with the curl (command-line HTTP client; on platforms that do not have it you might use wget as well, or many other equivalent methods to GET an HTTP request) to trigger the lazy-merge attempt (or fail one, does not matter here) so the git refspecs are re-calculated.

      This workaround as described only applies if you have PR poller and actual builder in separate jobs. Otherwise, CI is checked out (with wrong refspec) before the build steps run. An alternative solution is to post the script provided below into "" category, but then you'd have to hardcode the username and password for Stash REST API access, it seems.

      # Workaround for broken git references that appear due to PRs,
      # popping up in other jobs trying to use just the master branch.
      # See and
      set +x
      echo "Triggering lazy-merge of the PR on stash, by inspecting the special URL..."
      curl -k http://${STASH_USERNAME}:${STASH_PASSWORD}${destinationRepositoryOwner}/repos/${destinationRepositoryName}/pull-requests/${pullRequestId}/merge

      Response from the command should be a meaningful JSON not with an authentication error (smile) In my case it was: 

       "vetoes":[{"summaryMessage":"Requires approvers","detailedMessage":"You need 1 more approval before this pull request can be merged."}]}

      The login values for curl come from Jenkins credential storage, courtesy of the Credentials Binding Plugin and how-to. In my simpler case, the credential was already stored and used for other REST API calls, and I only had to click Build Environment / Use secret text(s) or file(s), and selected a "Username and password (separated)" which I named STASH_USERNAME and STASH_PASSWORD, and picked the same credential used for the Stash-Jenkins PR integration. Note that if you don't use set +x, Jenkins should replace the credentials by asterisks in the log; but better safe than sorry (wink)

      Note that in our case the credentials are chosen to not upset the URL parser (no special characters that are part of URL markup and must be percent-encoded); you may have to add the encoder into the script above if your passwords use the @:/ and similarly important characters.

  4. What is the difference of this plugin to the bitbucket-pullrequest-builder-plugin?

    Are they solving different problems, is one of them deprecated, or are they just two alternatives created by different authors?

    1. I'd say the primary one is on the tin, per their READMEs, one is for (the cloud service), the other is for on-premise Stash instances (later rebranded to Bitbucket name as well). "This plugin was inspired by the GitHub & BitBucket pull request builder plugins." - this likely explains why many configuration variables are named the same.

      There may be functional differences as well (e.g. with Stash PR builder, we can set up the URL to the instance as a global Jenkins config value, and individual PR jobs just use that), not sure if there's something else. Not even sure which one end up in our case to query and build the on-premise Stash we track as an Organization Folder with the Pipeline support - likely that other one. In the end we've kept both older dedicated PR jobs and the new pipeline support active, because Stash PR builder can query the magic Stash REST API to recalculate ephemeral PR branches before build, so they can be resolved as the target (e.g. upstream/master) branch state changes; had some issues without that feature active.

  5. Thanks for the previous answers. I now managed to set up a working Jenkins job that correctly triggers on pull requests.

    However, manually triggering of my job causes a build failure, because the variables ${destinationRepositoryOwner} and ${destinationRepositoryName} are unknown in that case. For example:

    1. build the master branch when triggered manually?
    2. disable manual triggers?
    1. Indeed, same for us. Just don't do it (smile)

      To rebuild a PR (e.g. after sporadic failure in code like race conditions, fixed issue on test-farm's side, updated scripts and other stuff outside the tested branch that can influence the results), go to the open pull request in Stash web-gui and add a comment that includes "test this please" (see above for syntax and additional setup like build arg passing).

  6. Where can I find the jobdsl syntax for this plugin?

    1. Job DSL is not supported yet.

  7. Is the use of wildcard supported under "Build PR targetting only these branches"? I could not get this to work.

    1. The documentation says it's a comma separated list of regexes. Regular expressions are not wildcards. Say, to test all release branches, the wildcard would be release/* whereas the regex would be release/.*

  8. Guys thanks for the great plugin! Quick question. Is there any way to attach code coverage information as part of this build status comment ? Has anyone done it ?

  9. Please fix getting the Jenkins root URL with the new Jenkins versions. Without the fix, the Stash posts have an error message instead of a link to Jenkins. The pull request is on GitHub:

    1. Note that you can build your own with `mvn package`.

      The HPI I use at work includes I think all or most of the PRs against the jenkins fork and nemccarthy's origin, which is easily done at home with a `git merge` while waiting for upstream to wake up.

      Hope this helps, Jim

  10. Hello Team,

    I am using    V#1.7.0  - I am facing issue with build trigger for type project.  Exactly same config is running for free-style or maven project but not for Pipeline project.

    Does anyone tried this? If working let me know the steps:- 

    Build Trigger config

    Jenkins SCM config

  11. Hi,

    I am trying to use the plugin (version 1.7.0), I receive the error-

    WARNING: failed for org.jenkinsci.plugins.workflow.job.WorkflowJob



    Any idea what is wrong?

    1. Support for pipelines is now in review, please test and report the results:

  12. Hi Pavel, thank you for maintaining this plugin.
    Maybe I missed something but we have issues with "Build PR targeting only these branches"

    PR are building fine until we try to add a branch name here. For example we would like to have different builds based on branch names like
    I tried to add in targeting branch name: "android" ".*android.*" "feature/.*android" with no success. Can you help me what am I missing here to make this pugin build only the android branches?

    Thank you in advance. 

    1. feature/XXX-1234-android-xxxxx sounds like a source branch. Target branch is the branch you want to merge into. I did test the feature when writing help files, it worked for me. Please open a ticket in the Jenkins bug tracking system, this is not a good medium for triaging bugs. Also, I'm not a maintainer of this plugin.

      I've just checked, a PR to merge my-pr into feature/XXX-1234-android-xxxxx is triggered if "Build PR targeting only these branches" is set to .*android.*