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

pr-merge status notification sent to GitHub applies to multiple PRs if source branch has multiple PRs opened to different target branches

XMLWordPrintable

      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.

          [JENKINS-62924] pr-merge status notification sent to GitHub applies to multiple PRs if source branch has multiple PRs opened to different target branches

          Liam Newman added a comment -

          drock
          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.

          Liam Newman added a comment - drock 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.

          Derrick Li added a comment -

          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).

          Derrick Li added a comment - 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).

          Liam Newman added a comment -

          drock
          Great! It sounds like you understand what is needed. Please submit a PR.

          Liam Newman added a comment - drock Great! It sounds like you understand what is needed. Please submit a PR.

          Alexander Komarov added a comment -

          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.

          Alexander Komarov added a comment - 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.

            Unassigned Unassigned
            drock Derrick Li
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: