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

GitHub commit status context not unique enough or configurable - jobs always overwrite each other

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      GitHub can incorrectly flag PRs as passing checks if multiple jobs run against the same repository.

      Multiple jobs configured against the same source repo will incorrectly set all checks successful if the last completed check is successful.

      In my opinion, if there is no mechanism to define mandatory and optional checks, then the worst status check should provide the overall result.

      This could be a check prior to submitting status that validates the prior status is not unsuccessful, and  it is the same git sha1, and it is a different job name.

      The secondary issue here is that only a single link is added to the PR, and so there is no indication on the GitHub PR how many jobs ran.

        Attachments

          Issue Links

            Activity

            Hide
            bitwiseman Liam Newman added a comment -

            Jon-Paul Sullivan
            What I meant was that JIRA says you changed this issue to "In Progress" and I wanted to know if you were working on it. If not, I'll change it back to open.

            Show
            bitwiseman Liam Newman added a comment - Jon-Paul Sullivan What I meant was that JIRA says you changed this issue to "In Progress" and I wanted to know if you were working on it. If not, I'll change it back to open.
            Hide
            j3p0uk Jon-Paul Sullivan added a comment -

            Nozomu Honda - as you changed the status to in progress, could you answer Liam Newman’s question please?

            Show
            j3p0uk Jon-Paul Sullivan added a comment - Nozomu Honda - as you changed the status to in progress, could you answer Liam Newman ’s question please?
            Hide
            nozomu_honda Nozomu Honda added a comment -

            Liam Newman Jon-Paul Sullivan

            Sorry for my late reply.

            I changed the status unintentionally. 

            Please change it back to open.

             

             

            Show
            nozomu_honda Nozomu Honda added a comment - Liam Newman   Jon-Paul Sullivan Sorry for my late reply. I changed the status unintentionally.  Please change it back to open.    
            Hide
            pascalhofmann Pascal Hofmann added a comment - - edited

            https://github.com/jenkinsci/github-scm-trait-notification-context-plugin works like a charm for me with multi branch pipelines. It is also configurable via job-dsl:

            // Defines a custom context label to be sent as part of Github Status notifications for this project.
            notificationContextTrait {
                // The text of the context label for Github status notifications.
                contextLabel(String value)
                // Appends the relevant suffix to the context label based on the build type.
                typeSuffix(boolean value)
            }

            Show
            pascalhofmann Pascal Hofmann added a comment - - edited https://github.com/jenkinsci/github-scm-trait-notification-context-plugin  works like a charm for me with multi branch pipelines. It is also configurable via job-dsl: // Defines a custom context label to be sent as part of Github Status notifications for this project. notificationContextTrait {     // The text of the context label for Github status notifications.     contextLabel (String value)     // Appends the relevant suffix to the context label based on the build type.     typeSuffix (boolean value) }
            Hide
            j3p0uk Jon-Paul Sullivan added a comment -

            Liam Newman, I finished rejoicing, but I'm not sure I'm ready to close this yet.

            I guess my main concern is that the default behaviour of Jenkins is one that allows loss of data and incorrect code merges.

            I would like to see can the default string be a safe alternative based on the job name in some way, rather than relying on either only a single job per repository, or the user knowing of the weakness and knowing to get the extra plugin to configure each of their jobs appropriately.

            Show
            j3p0uk Jon-Paul Sullivan added a comment - Liam Newman , I finished rejoicing, but I'm not sure I'm ready to close this yet. I guess my main concern is that the default behaviour of Jenkins is one that allows loss of data and incorrect code merges. I would like to see can the default string be a safe alternative based on the job name in some way, rather than relying on either only a single job per repository, or the user knowing of the weakness and knowing to get the extra plugin to configure each of their jobs appropriately.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              j3p0uk Jon-Paul Sullivan
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated: