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

Github organisation PR -merge builds don't run if master updated

    Details

    • Similar Issues:

      Description

      When creating a PR, Jenkins will build the -head and -merge correctly.

      However, when the source branch of the PR (e.g. master) is updated, the PR-merge branch is not triggered to rebuild / test with the updated master.

        Attachments

          Issue Links

            Activity

            Hide
            bragdonjm Jeff Bragdon added a comment -

            I am also seeing this in different versions of Jenkins.

            Show
            bragdonjm Jeff Bragdon added a comment - I am also seeing this in different versions of Jenkins.
            Hide
            bragdonjm Jeff Bragdon added a comment -

            Tested in Jenkins 2.53, 2.57, and 2.46.2 – This seems to have come about during the merging of the github org folder plugin to github branch source plugin.

             

            I've totally rebuilt from scratch 2.57 and 2.46.2 taking care to redo all configurations to ensure it was not some latent upgrade configuration problem.

            Test Params: 

            1. Open two PRs (One waiting, one merging)
            2. Ensure both are testing successfully (unit tests)
            3. Merge PR1 --> Master
            4. Master will rebuild. The expected behavior is PR2 will also rebuild (Merge with new master and test) — It will not.

            A rescan of the org or the repo will cause Jenkins to finally rebuild PR2 with the updated master. It is almost like there is a missing rescan after push detection happening in the github branch source plugin or Branch API plugin. 

            Show
            bragdonjm Jeff Bragdon added a comment - Tested in Jenkins 2.53, 2.57, and 2.46.2 – This seems to have come about during the merging of the github org folder plugin to github branch source plugin.   I've totally rebuilt from scratch 2.57 and 2.46.2 taking care to redo all configurations to ensure it was not some latent upgrade configuration problem. Test Params:  Open two PRs (One waiting, one merging) Ensure both are testing successfully (unit tests) Merge PR1 --> Master Master will rebuild. The expected behavior is PR2 will also rebuild (Merge with new master and test) — It will not. A rescan of the org or the repo will cause Jenkins to finally rebuild PR2 with the updated master. It is almost like there is a missing rescan after push detection happening in the github branch source plugin or Branch API plugin. 
            Hide
            bragdonjm Jeff Bragdon added a comment -

            Found this: 

             

            With GitHub Branch Source 2.0.0-beta-1 (available from the experimental update center now or 2.0.0 (available in early January 2017)

            When you push a change to the base branch, it should trigger only the base branch. The PR-merge branches will get rebuilt when the indexing kicks in as indexing will detect that the merge commit is now different, but that should only happen once a day/week (depending on how often you configure indexing) so should be much less of an issue

             

            ^ We want the option to have the old behaviour

            Show
            bragdonjm Jeff Bragdon added a comment - Found this:    With GitHub Branch Source 2.0.0-beta-1 (available from the experimental update center now or 2.0.0 (available in early January 2017) When you push a change to the base branch, it should trigger only the base branch. The PR-merge branches will get rebuilt when the indexing kicks in as indexing will detect that the merge commit is now different, but that should only happen once a day/week (depending on how often you configure indexing) so should be much less of an issue   ^ We want the option to have the old behaviour
            Hide
            discobean Mariusz added a comment - - edited

            +1 for that option, unfortunately we have an extremely large github repository and indexing of the repo takes over a day to run. So indexing is off for us, and we just use hooks.

            Show
            discobean Mariusz added a comment - - edited +1 for that option, unfortunately we have an extremely large github repository and indexing of the repo takes over a day to run. So indexing is off for us, and we just use hooks.

              People

              • Assignee:
                Unassigned
                Reporter:
                discobean Mariusz
              • Votes:
                7 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated: