Status: Open (View Workflow)
Jenkins ver. 2.204.5
GitHub API 1.111
GitHub Branch Source 2.7.1
If multiple, simultaneous PRs are opened for single source branch to different target branches, e.g. a PR to dev and a PR to master, the pr-merge status notification received by GitHub will apply the status notification to all PRs when it should only apply to a single PR.
- relates to
JENKINS-55726 GitHub commit status context not unique enough or configurable - jobs always overwrite each other
Understandable. A simple restriction can be implemented by failing the builds if multiple PRs are detected and informing the user on the PR (via GitHub's API).
Great! It sounds like you understand what is needed. Please submit a PR.
This may not be the most common scenario, but where I work it is policy - daggy fixes are used whenever possible.
This means that we try to make fixes as close to the commit that introduced the bug. So I will routinely rebase a fix onto an old commit (before branches were made), then open 3 PRs for 3 maintenance release branches (target branches).
The issue here is that Jenkins reports that the fix commit was successfully built (or not), rather than reporting that the merge commit (fix -> target branch) was built. GitHub then marks all 3 PRs green/red, according to whichever job finished last, allowing bad PRs to be merged.
I'm pretty sure this is because the plugin uses github commit status. JENKINS-55726 might also effect this.
Valid bug, though not the most common scenario.