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

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

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • None
    • CloudBees Jenkins Enterprise 2.107.34.0.1-fixed
      GitHub API Plugin 1.90
      GitHub Branch Source Plugin 2.3.5

      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.

          [JENKINS-55726] GitHub commit status context not unique enough or configurable - jobs always overwrite each other

          Jesse Glick added a comment -

          Sorry, will leave detailed responses to whomever currently maintains the GitHub integration.

          Jesse Glick added a comment - Sorry, will leave detailed responses to whomever currently maintains the GitHub integration.

          Liam Newman added a comment -

          j3p0uk
          there is this plugin that lets people notify github in whatever way they choose.
          https://github.com/jenkinsci/pipeline-githubnotify-step-plugin

          Generally, the assumption for Pipeline has been that there is one pipeline per repository, so it was safe to have a hard-coded context. Are you not using Pipeline or using more than one pipeline per repository?

          In any case, having the github-branch-source support a user configurable context string seems like a reasonable feature request. Would you be willing to submit a PR for this?

          Liam Newman added a comment - j3p0uk there is this plugin that lets people notify github in whatever way they choose. https://github.com/jenkinsci/pipeline-githubnotify-step-plugin Generally, the assumption for Pipeline has been that there is one pipeline per repository, so it was safe to have a hard-coded context. Are you not using Pipeline or using more than one pipeline per repository? In any case, having the github-branch-source support a user configurable context string seems like a reasonable feature request. Would you be willing to submit a PR for this?

          Liam Newman added a comment - - edited

          FYI - Rejoice everyone!
          This functionality is available here:
          "Github Custom Notification Context SCM Behaviour"
          https://github.com/jenkinsci/github-scm-trait-notification-context-plugin

          Liam Newman added a comment - - edited FYI - Rejoice everyone! This functionality is available here: "Github Custom Notification Context SCM Behaviour" https://github.com/jenkinsci/github-scm-trait-notification-context-plugin

          Liam Newman added a comment -

          j3p0uk
          I see you changed this to in-progress. What else needs to be done here?

          Liam Newman added a comment - j3p0uk I see you changed this to in-progress. What else needs to be done here?

          bitwiseman, I did not change it, but I do think that the default behaviour of the plugin should not be one that allows information loss.

          Jon-Paul Sullivan added a comment - bitwiseman , I did not change it, but I do think that the default behaviour of the plugin should not be one that allows information loss.

          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.

          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?

          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 added a comment -

          bitwiseman j3p0uk

          Sorry for my late reply.

          I changed the status unintentionally. 

          Please change it back to open.

           

           

          Nozomu Honda added a comment - bitwiseman   j3p0uk Sorry for my late reply. I changed the status unintentionally.  Please change it back to open.    

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

          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.

          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.

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

              Created:
              Updated: