Add the ability to use branch source than integrated PR source for Pull Request builds

XMLWordPrintable

    • Type: New Feature
    • Resolution: Unresolved
    • Priority: Minor
    • Environment:

      We're recently switch to atlassian-bitbucket-server-integration-plugin from cloudbees-bitbucket-branch-source as the branch indexing was taking too long saturating the SCMEvent queue, resulting in builds not automatically triggering.

      After changing to this plugin, we've managed to resolve this problem for all repositories except one. We have a large repository in Bitbucket server,
       * 10GB in size (as per Bitbucket UI)
       * 2500 branches approximately
       * 150 open Pull Requests

      With the current behaviour of atlassian-bitbucket-server-integration-plugin, it does a Jenkins server side merge of the PR code with the destination branch, which ends up checking out this large repository to just to check the merge, and then is not used at all for the build as the Jenkins agent nodes later does checkouts to perform the same merge before running the build.

      In cloudbees-bitbucket-branch-source, there's an option for PRs to use the HEAD of the source branch instead of the merged result of PR to destination, which avoids the whole need to do this merge at the start of the build, with the caveat of the branch build using the Jenkinsfile also from the branch than a merged one, but this was small cost for making this repository work. 

      The suggested feature here is to make it possible to decided between "PR merged to destination" vs "source branch" for PR builds, and when latter is selected, skip the Jenkins server side Git activity that requires a fetch with history and just get the Jenkinsfile with a depth 1 single branch clone.

            Assignee:
            Unassigned
            Reporter:
            Venushka Perera
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: