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

Build Origin PRs (merge with base branch) conducts rebuilds when baseline changes

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • None
    • github-branch-source 1.8.1
      jenkins 2.18

      When 'Build Origin PRs (merge with base branch)' is selected any PR's which are filed against a base branch are re-triggered when the base branch changes.

      While this is all fine if you have a small # of PR's & the builds are quick, if you have a large team & backlog of PR's then any merge to the base branch will automatically trigger every PR which is using the same baseline.

      When you then end up with is a Jenkins that has a massive queue to process & github often complaining that you've exceeded the API rate limit.

      The concept of building the merge branch is great, however at the moment I really can't use it because of the previously stated behaviour & causes massive issues for our builds.

      Previous versions of the plugin didn't exhibit this behaviour at all, nor do other systems like travis which build PR's using the merge branch, nor did the github pull request builder plugin.

      As a workaround I'm forced to use the 'Build Origin PRs (unmerged HEAD)' and then conduct the merge or checkout of the GH merge branch itself within the pipeline which is less than ideal.

      Can we have an option to inhibit a re-trigger when the baseline changes for PRs with merge?

      btw I like where this plugin is going

          [JENKINS-37491] Build Origin PRs (merge with base branch) conducts rebuilds when baseline changes

          > but it currently also disables all builds caused by events (such as webhooks, etc.) so it's not super useful for much right now.

          Actually there is a cohort of people who consider this behaviour as exactly the behaviour that they want... they want the branch projects created but they do not want those branch projects to ever have an automatic build.

          My intent is to remove that property (should never have been added) and replace it with the concept of interesting heads/revisions and non-interesting heads/revisions (JENKINS-45502) so for that reason I will most likely reject PRs on this functionality against the branch-api plugin (as these kinds of tweaks should not be taking place in the branch-api plugin) Feel free to create an extension plugin that provides the behaviour you want. I will merge PRs that enable extension plugins to do this kind of thing, with the proviso that I believe JENKINS-45502 is the correct direction

          Stephen Connolly added a comment - > but it currently also disables all builds caused by events (such as webhooks, etc.) so it's not super useful for much right now. Actually there is a cohort of people who consider this behaviour as exactly the behaviour that they want... they want the branch projects created but they do not want those branch projects to ever have an automatic build. My intent is to remove that property (should never have been added) and replace it with the concept of interesting heads/revisions and non-interesting heads/revisions ( JENKINS-45502 ) so for that reason I will most likely reject PRs on this functionality against the branch-api plugin (as these kinds of tweaks should not be taking place in the branch-api plugin) Feel free to create an extension plugin that provides the behaviour you want. I will merge PRs that enable extension plugins to do this kind of thing, with the proviso that I believe JENKINS-45502 is the correct direction

          Spencer Malone added a comment - - edited

          But those that want to disable all options could just use both 

          properties([overrideIndexTriggers(false), overrideEventTriggers(false)])

          My problem is that currently, those of us that want organization scans to not trigger builds, but still want to run them for the other things they do (such as old branch job cleanup, or finding "lost" PRs) are kind of left without a way to do what we need. This patch lets people choose their default behavior on a per-branch basis.

          I agree that the original property seems like a mistake when combined with everything else.

          How far out is the interesting head/revision idea? I understand the desire to push forward on a big revision like that, but this has been a pretty big blocker for us for a while. The patch is relatively simple, and it seems like the interesting head/revision stuff is way off on the horizon. Currently this is a key issue that we're feeling every day. 

           

          EDIT: Sorry, after rereading, I see more of the emphasis on the creating extension points. I'll look into that, but this is my first contribution to jenkins plugins, so it'll take me some time to get used to how extensions work.

          Spencer Malone added a comment - - edited But those that want to disable all options could just use both  properties([overrideIndexTriggers(false), overrideEventTriggers(false)]) My problem is that currently, those of us that want organization scans to not trigger builds, but still want to run them for the other things they do (such as old branch job cleanup, or finding "lost" PRs) are kind of left without a way to do what we need. This patch lets people choose their default behavior on a per-branch basis. I agree that the original property seems like a mistake when combined with everything else. How far out is the interesting head/revision idea? I understand the desire to push forward on a big revision like that, but this has been a pretty big blocker for us for a while. The patch is relatively simple, and it seems like the interesting head/revision stuff is way off on the horizon. Currently this is a key issue that we're feeling every day.    EDIT: Sorry, after rereading, I see more of the emphasis on the creating extension points. I'll look into that, but this is my first contribution to jenkins plugins, so it'll take me some time to get used to how extensions work.

          Jesse Glick added a comment -

          This is something that should be solved in github-branch-source, not branch-api, though a common extension in scm-api might be useful so the same UI can be reused for BitBucket etc.

          Jesse Glick added a comment - This is something that should be solved in github-branch-source , not branch-api , though a common extension in scm-api might be useful so the same UI can be reused for BitBucket etc.

          Joshua Noble added a comment - - edited

          I'm also now seeing build storms from this issue.

          One can turn off "Periodically if not otherwise run" to prevent the storms, but then you're left with orphaned jobs being left behind when a branch is deleted. Therefore, if one tries to use the branch source plugin, they either have to deal with build storms, or with orphaned jobs.

          I don't think I saw this issue back when the core functionality existed in the GitHub Organization Folders plugin. Perhaps this is a regression?

          Joshua Noble added a comment - - edited I'm also now seeing build storms from this issue. One can turn off "Periodically if not otherwise run" to prevent the storms, but then you're left with orphaned jobs being left behind when a branch is deleted. Therefore, if one tries to use the branch source plugin, they either have to deal with build storms, or with orphaned jobs. I don't think I saw this issue back when the core functionality existed in the GitHub Organization Folders plugin. Perhaps this is a regression?

          For the record, if you want to avoid triggering rebuilds when just the target branch of the PR has changed then you want https://github.com/jenkinsci/basic-branch-build-strategies-plugin/blob/master/docs/user.adoc#change-requests 

           

          IMHO this problem is closed by the feature "Ignore rebuilding merge branches when only the target branch changed" in the Basic Branch Build Strategy plugin's "Change Requests" strategy

          Stephen Connolly added a comment - For the record, if you want to avoid triggering rebuilds when just the target branch of the PR has changed then you want https://github.com/jenkinsci/basic-branch-build-strategies-plugin/blob/master/docs/user.adoc#change-requests     IMHO this problem is closed by the feature "Ignore rebuilding merge branches when only the target branch changed" in the Basic Branch Build Strategy plugin's "Change Requests" strategy

          Resolution:

          • Install Basic Branch Build Strategies plugin and add the "Change Requests" with "Ignore rebuilding merge branches when only the target branch changed" selected to your build strategies

          Stephen Connolly added a comment - Resolution: Install Basic Branch Build Strategies plugin and add the "Change Requests" with "Ignore rebuilding merge branches when only the target branch changed" selected to your build strategies

          Jesse Glick added a comment -

          For safety, you may want to then configure GitHub to refuse to let PRs be merged unless they are up to date with the base branch—IOW to only permit fast-forward merges from the GUI.

          Jesse Glick added a comment - For safety, you may want to then configure GitHub to refuse to let PRs be merged unless they are up to date with the base branch—IOW to only permit fast-forward merges from the GUI.

          Joshua Noble added a comment -

          I can confirm that setting up the Basic Branch Build Strategies plugin and selecting Regular Branches and Change Requests (with Ignore rebuilding merge branches checked) indeed gives us exactly what we want. Thanks for the tip!

          Joshua Noble added a comment - I can confirm that setting up the Basic Branch Build Strategies plugin and selecting Regular Branches and Change Requests (with Ignore rebuilding merge branches checked) indeed gives us exactly what we want. Thanks for the tip!

          stephenconnolly hey, i've installed the plugins, but i can't find the options on my multiple pipeline job .. Could you help me please ?

          Aldo Christian added a comment - stephenconnolly hey, i've installed the plugins, but i can't find the options on my multiple pipeline job .. Could you help me please ?

          Brian J Murrell added a comment - - edited

          aldochristiaan By multiple pipeline job do you mean GitHub Organisation jobs?  Because I agree, the proposed solution here doesn't seem to apply, AFAICT, to the GitHub Source Branch Plugin multibranch-pipeline job.

          So those users still need a solution to these build storms that just take down your Jenkins machine every time a base branch (i.e. master) is updated.  I guess we need another ticket.

          Brian J Murrell added a comment - - edited aldochristiaan By multiple pipeline job do you mean GitHub Organisation jobs?  Because I agree, the proposed solution here doesn't seem to apply, AFAICT, to the GitHub Source Branch Plugin multibranch-pipeline job. So those users still need a solution to these build storms that just take down your Jenkins machine every time a base branch (i.e. master) is updated.  I guess we need another ticket .

            Unassigned Unassigned
            nullify005 Lee Webb
            Votes:
            6 Vote for this issue
            Watchers:
            20 Start watching this issue

              Created:
              Updated:
              Resolved: