• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major

      As of today, the commit status updating of my multipipeline project stopped working, and I'm seeing the following error in the logs:

      Could not update commit status. Message: {"message":"Not Found","documentation_url":"https://developer.github.com/enterprise/2.8/v3"}
      

      The following changes were made since the last time things were working:

      • Upgraded all jenkins plugin (last update was ~2 weeks ago)
      • Re-created my scan credentials token as a "username/password" token since I'm unable to use my old "secret text" token since upgrading: see https://issues.jenkins-ci.org/browse/JENKINS-39086

      I think the token itself is okay. It has the 'repo:status' scope, and I'm able to manually create a commit statuses with it using the GH API via curl.

      Perhaps this is a recent regression causing the wrong HTTP request to be made for creating the commit status? Perhaps limited to GH Enterprise?

      I'm happy to provide more information, but I don't know how to get more debugging info on the actual http request that is causing the problem.

          [JENKINS-41750] commit status updating broken

          I found a workaround:

          I had to add my GitHub token twice. Once as a "secret text" and once as a "username password" token. I also had to make both credentials globals. After that I was able to use the "username password" credential for my GitHub Organization job (the "secret text" token is not listed in the drop down) and the "secret text" token in the "Manage Jenkins" -> "Configure System" settings (the "username password" token doesn't show in the drop down there).

          This is really confusing, so I'm wondering if I'm still doing something wrong, or if there is a bug that needs fixing here.

          Felix Geisendörfer added a comment - I found a workaround: I had to add my GitHub token twice. Once as a "secret text" and once as a "username password" token. I also had to make both credentials globals. After that I was able to use the "username password" credential for my GitHub Organization job (the "secret text" token is not listed in the drop down) and the "secret text" token in the "Manage Jenkins" -> "Configure System" settings (the "username password" token doesn't show in the drop down there). This is really confusing, so I'm wondering if I'm still doing something wrong, or if there is a bug that needs fixing here.

          James Dumay added a comment - - edited

          campbellr stephenconnolly heres an interesting one. Seems to be present in github org folder 1.5 though.

          James Dumay added a comment - - edited campbellr stephenconnolly heres an interesting one. Seems to be present in github org folder 1.5 though.

          hrmpw jdumay So if I understand this correctly this is the confusion between the two different paths for authentication between the GitHub plugin and the GitHub Branch Source Plugin. When we tackle the two different Global Config GitHub server definitions we should be able to sort this out.

          Also, I suspect the GitHub plugin is not using the Credentials plugin optimally, so that is likely a source for further user confusion.

          At present, you basically need to have two sets of credentials with the same secret (which completely defeats the point of the credentials plugin). The use of a "secret text" credential for authentication against GitHub is not the way it should work, as there is no way that a GitHub API token could ever be valid against anything other than GitHub. As such there should be a dedicated credential type for GitHub API tokens and then this would all be much easier for users to set up... probably resolving this issue should be blocked by me getting time to document the consumer, user and implementer guides for the credentials plugin.

          Stephen Connolly added a comment - hrmpw jdumay So if I understand this correctly this is the confusion between the two different paths for authentication between the GitHub plugin and the GitHub Branch Source Plugin. When we tackle the two different Global Config GitHub server definitions we should be able to sort this out. Also, I suspect the GitHub plugin is not using the Credentials plugin optimally, so that is likely a source for further user confusion. At present, you basically need to have two sets of credentials with the same secret (which completely defeats the point of the credentials plugin). The use of a "secret text" credential for authentication against GitHub is not the way it should work, as there is no way that a GitHub API token could ever be valid against anything other than GitHub. As such there should be a dedicated credential type for GitHub API tokens and then this would all be much easier for users to set up... probably resolving this issue should be blocked by me getting time to document the consumer, user and implementer guides for the credentials plugin.

          Thanks for the update!

          Felix Geisendörfer added a comment - Thanks for the update!

            cloudbees CloudBees Inc.
            felixge Felix Geisendörfer
            Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: