Fallback to conservative approach if repo collaborators cannot be retrieved

This issue is archived. You can view it, but you can't modify it. Learn more

XMLWordPrintable

      Due to temporary change in GitHub change the required repository permission to list collaborators from Write to Admin, the multibranches of many users were not able to process events / run indexing properly as it would now fail with:

      Waiting for GitHub to create a merge commit for pull request 1.  Retrying 4 more times...
        Error while processing pull request 1
      java.io.FileNotFoundException: https://api.github.com/repos/test-org/test-repo/collaborators/test-user/permission
      	at org.kohsuke.github.extras.okhttp3.ObsoleteUrlFactory$OkHttpURLConnection.getInputStream(ObsoleteUrlFactory.java:490)
      	at org.kohsuke.github.extras.okhttp3.ObsoleteUrlFactory$DelegatingHttpsURLConnection.getInputStream(ObsoleteUrlFactory.java:1204)
      	at org.kohsuke.github.GitHubHttpUrlConnectionClient$HttpURLConnectionResponseInfo.bodyStream(GitHubHttpUrlConnectionClient.java:196)
      	at org.kohsuke.github.GitHubResponse$ResponseInfo.getBodyAsString(GitHubResponse.java:314)
      	at org.kohsuke.github.GitHubResponse.parseBody(GitHubResponse.java:92)
      	at org.kohsuke.github.Requester.lambda$fetch$1(Requester.java:76)
      	at org.kohsuke.github.GitHubClient.createResponse(GitHubClient.java:455)
      	at org.kohsuke.github.GitHubClient.sendRequest(GitHubClient.java:406)
      Caused: org.kohsuke.github.GHFileNotFoundException: https://api.github.com/repos/test-org/test-repo/collaborators/test-user/permission {"message":"Not Found","documentation_url":"https://docs.github.com/enterprise/3.1/rest/reference/repos#get-repository-permissions-for-a-user"}
      	at org.kohsuke.github.GitHubClient.interpretApiError(GitHubClient.java:486)
      	at org.kohsuke.github.GitHubClient.sendRequest(GitHubClient.java:414)
      	at org.kohsuke.github.GitHubClient.sendRequest(GitHubClient.java:358)
      	at org.kohsuke.github.Requester.fetch(Requester.java:76)
      	at org.kohsuke.github.GHRepository.getPermission(GHRepository.java:948)
      	at org.jenkinsci.plugins.github_branch_source.GitHubSCMSource$1.fetch(GitHubSCMSource.java:1031)
      	at org.jenkinsci.plugins.github_branch_source.GitHubSCMSourceRequest.getPermissions(GitHubSCMSourceRequest.java:450)
      	at org.jenkinsci.plugins.github_branch_source.ForkPullRequestDiscoveryTrait$TrustPermission.checkTrusted(ForkPullRequestDiscoveryTrait.java:323)
      	at org.jenkinsci.plugins.github_branch_source.ForkPullRequestDiscoveryTrait$TrustPermission.checkTrusted(ForkPullRequestDiscoveryTrait.java:310)
      	at jenkins.scm.api.trait.SCMHeadAuthority.isTrusted(SCMHeadAuthority.java:101)
      	at jenkins.scm.api.trait.SCMSourceRequest.isTrusted(SCMSourceRequest.java:213)
      	at org.jenkinsci.plugins.github_branch_source.GitHubSCMSource$4.create(GitHubSCMSource.java:1265)
      	at org.jenkinsci.plugins.github_branch_source.GitHubSCMSource$4.create(GitHubSCMSource.java:1259)
      	at jenkins.scm.api.trait.SCMSourceRequest.process(SCMSourceRequest.java:339)
      	at org.jenkinsci.plugins.github_branch_source.GitHubSCMSource.retrievePullRequest(GitHubSCMSource.java:1256)
      	at org.jenkinsci.plugins.github_branch_source.GitHubSCMSource.retrieve(GitHubSCMSource.java:1094)
      	at jenkins.scm.api.SCMSource._retrieve(SCMSource.java:373)
      	at jenkins.scm.api.SCMSource.fetch(SCMSource.java:283)
      	at jenkins.branch.MultiBranchProject.computeChildren(MultiBranchProject.java:642)
      	at com.cloudbees.hudson.plugins.folder.computed.ComputedFolder.updateChildren(ComputedFolder.java:278)
      	at com.cloudbees.hudson.plugins.folder.computed.FolderComputation.run(FolderComputation.java:166)
      	at jenkins.branch.MultiBranchProject$BranchIndexing.run(MultiBranchProject.java:1033)
      	at hudson.model.ResourceController.execute(ResourceController.java:100)
      	at hudson.model.Executor.run(Executor.java:433)
      

      Per a discussion with jglick, this is rather unexpected and in such a case, the Jenkinsfile should not be trusted:

      > So for some reason it seems that the code in https://github.com/jenkinsci/github-branch-source-plugin/blob/923184ce70fc84252937b8d08872f666efcc288b/src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSource.java#L1608-L1618 is not working as intended. It should be handling the case that the scan credentials lack permission for this API endpoint, by printing a one-line message and proceeding under the conservative assumption that the author of the forked PR is not a collaborator and so Jenkinsfile should not be trusted. (Docs: https://github.com/jenkinsci/github-branch-source-plugin/blob/923184ce70fc84252937b8d08872f666efcc288b/src/main/resources/org/jenkinsci/plugins/github_branch_source/ForkPullRequestDiscoveryTrait/help-trust.html#L20-L29)

      The 404 should be gracefully handled:

      > plan to at least fix the 404 handling to print "Not permitted to query list of collaborators, assuming none" and continue as untrusted, as the code was written to do.

      How to Reproduce

      • Need a repo
      • Need a fork
      • Create a PR from fork for any kind of user (collaborator or no, does not matter for that particular issue)
      • create a Multibranch:
      • use the credentials (username / Personal Access Token) of a user that has Read permissions on the repo
      • only discover PR from Forks, and set Trust to anything but "Everyone"

      Note: The other trust strategies “Collaborators“, “Nobody“ and “Everyone” work as designed. Actually the Trust strategy “Collaborators” fallbacks as expected: Not permitted to query list of collaborators, assuming none

            Assignee:
            Allan BURDAJEWICZ
            Reporter:
            Allan BURDAJEWICZ
            Archiver:
            Jenkins Service Account

              Created:
              Updated:
              Resolved:
              Archived: