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

    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

            bitwiseman Liam Newman added a comment -

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

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

            nozomu_honda - as you changed the status to in progress, could you answer bitwiseman’s question please?

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

            bitwiseman j3p0uk

            Sorry for my late reply.

            I changed the status unintentionally. 

            Please change it back to open.

             

             

            nozomu_honda Nozomu Honda added a comment - bitwiseman   j3p0uk Sorry for my late reply. I changed the status unintentionally.  Please change it back to open.    
            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)
            }

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

            bitwiseman, 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.

            j3p0uk Jon-Paul Sullivan added a comment - bitwiseman , 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

              Unassigned Unassigned
              j3p0uk Jon-Paul Sullivan
              Votes:
              1 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated: