Status: Open (View Workflow)
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.
- relates to
JENKINS-35674 Pull requests not rebuilt when destination commit changes
JENKINS-37491 Build Origin PRs (merge with base branch) conducts rebuilds when baseline changes
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.
- 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.
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.
I am also seeing this in different versions of Jenkins.