Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
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
- relates to
-
-
- Open
-
-
-
- Closed
-
Activity
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.
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. 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
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 +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.
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. 
I am also seeing this in different versions of Jenkins.