Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-51936

Reduce trigger-happy building from master/upstream commits

    Details

    • Similar Issues:

      Description

      Use case:

      • We have many PRs in-flight at any point in time. Often many of these are already-green PRs which are just waiting for code review to finish, but code review can often take a long time.
      • Many times a day, a PR actually gets to merge, and new commits appear on master.
      • We have a finite amount of resources available in our build farm, so we can't afford to run N(PRs) jobs for every commit. In fact, we're already paring down what we do test in PRs, because running the full suite on all supported platforms ties up too many resources.

      Current behaviour:

      • When the hourly scan of the repository comes around, all new commits to master trigger all PRs to rebuild.
      • Rebuilding all PRs locks up the build farm for a long period of time, delaying all other PRs (typically noticed when the change in the PR you're trying to get built seems much more important than the others) while it rebuilds ones which have already passed.

      What we'd prefer:

      • When a new commit appears on master, it doesn't trigger a rebuild of all PRs at all.
      • We do acknowledge that, yes, if a change goes into master, the PR might now be failing. But we don't have the budget to allocate enough resources to actually handle the ideal case, no matter how nice it would be to have that kind of budget. We're a big project with a lot of code, but we're not a Google and can't afford to throw money at the problem, even though it does seem like money is the only issue here.
      • Developers can still manually merge master to their PR branch, which would then be a change in the actual PR branch, and would trigger a rebuild like normal.

      I looked around for settings which might enable this kind of behaviour and I didn't see anything which looked like it could do this, but it's possible that I missed something.

       

        Attachments

          Activity

          trejkaz trejkaz created issue -
          markewaite Mark Waite made changes -
          Field Original Value New Value
          Attachment github-discover-current-pull-request-revision.PNG [ 42862 ]
          Attachment bitbucket-discover-current-pull-request-revision.PNG [ 42863 ]
          Hide
          markewaite Mark Waite added a comment -

          I think the use case you want is already covered by the GitHub branch source and the Bitbucket branch source. They both have an option to discover pull requests as:

          • The current pull request revision (which I think you want)
          • Merging the pull request with the current target branch version (which I think you're seeing now)
          • Both the current pull request revision and merging the pull request with the current target branch version

          The bitbucket branch source:

          The GitHub branch source:

          If you can confirm that meets your need, could you mark this as resolved?

          Show
          markewaite Mark Waite added a comment - I think the use case you want is already covered by the GitHub branch source and the Bitbucket branch source. They both have an option to discover pull requests as: The current pull request revision (which I think you want) Merging the pull request with the current target branch version (which I think you're seeing now) Both the current pull request revision and merging the pull request with the current target branch version The bitbucket branch source: The GitHub branch source: If you can confirm that meets your need, could you mark this as resolved?
          markewaite Mark Waite made changes -
          Assignee Mark Waite [ markewaite ]
          Hide
          trejkaz trejkaz added a comment -

          Hmm, it might. I was under the impression that we did still want to merge with the latest master when the build does run, but maybe losing that is acceptable considering the alternative.

          I'll have to check.

          Show
          trejkaz trejkaz added a comment - Hmm, it might. I was under the impression that we did still want to merge with the latest master when the build does run, but maybe losing that is acceptable considering the alternative. I'll have to check.
          Hide
          trejkaz trejkaz added a comment -

          After discussing this one with team members and others, I can confirm that we do still want to merge with the latest master if someone manually requests a new build, but that we still don't want new builds to kick off automatically for every change on master.

          Show
          trejkaz trejkaz added a comment - After discussing this one with team members and others, I can confirm that we do still want to merge with the latest master if someone manually requests a new build, but that we still don't want new builds to kick off automatically for every change on master.
          Hide
          markewaite Mark Waite added a comment -

          trejkaz I'm not aware of any user interface setting that will cause "Build now" to perform a merge with the master branch without also causing each change to the master branch to run the build. I suspect that use case might be possible to cover by creating a new plugin which adds that behavior as a branch discovery implementation. That is how the multibranch Pipeline implementation has been generally guiding implementations of specialized behaviors.

          You might also be able to implement the merge in your Jenkinsfile as a call to the git command line to perform the merge.

          Show
          markewaite Mark Waite added a comment - trejkaz I'm not aware of any user interface setting that will cause "Build now" to perform a merge with the master branch without also causing each change to the master branch to run the build. I suspect that use case might be possible to cover by creating a new plugin which adds that behavior as a branch discovery implementation. That is how the multibranch Pipeline implementation has been generally guiding implementations of specialized behaviors. You might also be able to implement the merge in your Jenkinsfile as a call to the git command line to perform the merge.

            People

            • Assignee:
              Unassigned
              Reporter:
              trejkaz trejkaz
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: