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

Details

    Description

      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.

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-55726 GitHub commit status context not unique enough or configurable - jobs always overwrite each other

          • Critical - Crashes, loss of data, severe memory leak.
          • Open

          Activity

            Ascending order - Click to sort in descending order
            bitwiseman 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.

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

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

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

            bitwiseman Liam Newman added a comment - drock Great! It sounds like you understand what is needed. Please submit a PR.
            akom 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.

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

            People

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

              Dates

                Created:
                Updated: