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

Jenkins 2.1 not registering GitHub org webhooks: "WARNING: Failed to register GitHub Org hook to ..."

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Won't Fix
    • Labels:
      None
    • Environment:
      Jenkins 2.1, github-organization-folder 1.3, github-api 1.75
    • Similar Issues:

      Description

      When creating a new job for a GitHub org, I'm seeing the following in the Jenkins logs:

      WARNING: Failed to register GitHub Org hook to https://github.com/karlmdavis (missing permissions?): {"message":"Not Found","documentation_url":"https://developer.github.com/v3"}
      May 04, 2016 8:03:46 PM org.jenkinsci.plugins.orgfolder.github.MainLogic applyOrg
      WARNING: Failed to register GitHub Org hook to https://github.com/HHSIDEAlab (missing permissions?): {"message":"Not Found","documentation_url":"https://developer.github.com/v3"}
      

      I did confirm that the personal access token I'm using has the admin:repo_hook permission, as well as admin:org_hook. Not sure what else to check.

      The plugin seems to work correctly aside from this: it finds projects with Jenkinsfile s and builds them when asked. Just no webhook triggers.

        Attachments

          Activity

          Hide
          stephenconnolly Stephen Connolly added a comment -

          The GitHub Org Folders plugin is being tombstoned.

          The functionality provided by the GitHub Org Folders plugin has been significantly refactored and migrated to the GitHub Branch Source plugin.

          Please verify if this issue is an issue with GitHub Branch Source 2.0.0-beta-1 (available from the experimental update center now or 2.0.0 (available in early January 2017)

          Show
          stephenconnolly Stephen Connolly added a comment - The GitHub Org Folders plugin is being tombstoned. The functionality provided by the GitHub Org Folders plugin has been significantly refactored and migrated to the GitHub Branch Source plugin. Please verify if this issue is an issue with GitHub Branch Source 2.0.0-beta-1 (available from the experimental update center now or 2.0.0 (available in early January 2017)
          Hide
          llibicpep Dee Kryvenko added a comment - - edited

          I've got that issue with GitHub Branch Source plugin, except that the error message from GitHub seems to change over the years.

          I got 4 identical GitHub Orgs, all accessed by a GitHub App. First one went fine, hook created no problems. The other 3 all fails with the error message:

          Failed to register GitHub Org hook to https://github.com/**** (missing permissions?): https://api.github.com/orgs/****/hooks {"message":"Resource not accessible by integration","documentation_url":"https://docs.github.com/rest/reference/orgs#list-organization-webhooks"}
          

          All orgs are using exactly the same one GitHub App. I couldn't reproduce that issue locally with other github orgs.

          Show
          llibicpep Dee Kryvenko added a comment - - edited I've got that issue with GitHub Branch Source plugin, except that the error message from GitHub seems to change over the years. I got 4 identical GitHub Orgs, all accessed by a GitHub App. First one went fine, hook created no problems. The other 3 all fails with the error message: Failed to register GitHub Org hook to https: //github.com /**** (missing permissions?): https://api.github.com/orgs/****/ hooks { "message" : "Resource not accessible by integration" , "documentation_url" : "https://docs.github.com/ rest /reference/orgs#list-organization-webhooks" } All orgs are using exactly the same one GitHub App. I couldn't reproduce that issue locally with other github orgs.
          Hide
          llibicpep Dee Kryvenko added a comment - - edited

          Ah, there's a clue. The one org that was successful actually owns that GitHub App, the other ones are just have it installed.

          Show
          llibicpep Dee Kryvenko added a comment - - edited Ah, there's a clue. The one org that was successful actually owns that GitHub App, the other ones are just have it installed.
          Hide
          llibicpep Dee Kryvenko added a comment - - edited

          GitHub support got back to me with the following finding: each application installation has its own token. Seems like my Jenkins instance was using the same token for all the installations. Further diving into the issue, the `Owner` field description for GitHub App credentials entry reads as this:

          The organisation or user that this app is to be used for. Only required if this app is installed to multiple organisations.

          This is not the owner of the App, it is an org that has this app installed! The name of the field is confusing. Also I am still confused as my Jenkins instance was successfully able to access private repos with the "wrong" token, it's just failing to manage webhooks.

          However, that means for each org I need to have its own credentials entry, even though it is the same App ID and key? I'm not sure this is expected/desired behavior. I want to be able to create the App and add its ID and token to my Jenkins instance, and then I want my Jenkins users to be able to install this App to their orgs and when they create jobs they should be able to use GitHub App credentials entry corresponding to this app. Current behavior requires me to be adding credentials entry separately for each org.

          I haven't looked into the code, but it should be possible to dynamically inject the `Owner` field before requesting the token based on the current SCM configuration in the job.

          Show
          llibicpep Dee Kryvenko added a comment - - edited GitHub support got back to me with the following finding: each application installation has its own token. Seems like my Jenkins instance was using the same token for all the installations. Further diving into the issue, the `Owner` field description for GitHub App credentials entry reads as this: The organisation or user that this app is to be used for . Only required if this app is installed to multiple organisations. This is not the owner of the App, it is an org that has this app installed! The name of the field is confusing. Also I am still confused as my Jenkins instance was successfully able to access private repos with the "wrong" token, it's just failing to manage webhooks. However, that means for each org I need to have its own credentials entry, even though it is the same App ID and key? I'm not sure this is expected/desired behavior. I want to be able to create the App and add its ID and token to my Jenkins instance, and then I want my Jenkins users to be able to install this App to their orgs and when they create jobs they should be able to use GitHub App credentials entry corresponding to this app. Current behavior requires me to be adding credentials entry separately for each org. I haven't looked into the code, but it should be possible to dynamically inject the `Owner` field before requesting the token based on the current SCM configuration in the job.
          Hide
          llibicpep Dee Kryvenko added a comment -

          I have filed https://issues.jenkins.io/browse/JENKINS-64249 to fix typos and improve documentation.

          I was going to file an improvement request based on the above comment, but it seems like there is two similar issues already open:

          https://issues.jenkins.io/browse/JENKINS-62220

          https://issues.jenkins.io/browse/JENKINS-62594

           

          Show
          llibicpep Dee Kryvenko added a comment - I have filed https://issues.jenkins.io/browse/JENKINS-64249  to fix typos and improve documentation. I was going to file an improvement request based on the above comment, but it seems like there is two similar issues already open: https://issues.jenkins.io/browse/JENKINS-62220 https://issues.jenkins.io/browse/JENKINS-62594  

            People

            Assignee:
            kohsuke Kohsuke Kawaguchi
            Reporter:
            karlmdavis karlmdavis
            Votes:
            2 Vote for this issue
            Watchers:
            7 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: