The handleIssueComment handler stopped working after GH chaged required permissions to fetch collaborators

[andrey-hura]

Version report

Jenkins and plugins versions report:

latest / all

• What Operating System are you using (both controller, and any agents involved in the problem)?

Linux

Reproduction steps

• Configure a GH organization folder to use a token with repository write permissions
• Create A PR and run a build with a PR phrase

Results

Expected result:
A build is started by the phrase

Actual result:
No new builds started
Jenkins error message:
WARNING o.j.p.p.g.t.GitHubEventSubscriber#handleIssueComment: Job: {jobname}, IssueComment: GHIssueComment@45e01ed3[{comment details}], Comment Author: {username} is not a collaborator, and is therefore not authorized to trigger a build.

GH recently changed the required permissions to fetch data from the repository/collaborators endpoint and all of our pipelines using the plugin stopped responding to PR phrases. I realize that the root cause of the issue is GH changes, but without the option to choose whether to allow non-collaborators the plugin won't work properly anymore.

[andrey-hura]

I would use contributors at least

[aaronwalker]

@andrey-hura so you had user who are outside contributors and this was working up until the API change, correct?

[andrey-hura]

@andrey-hura so you had user who are outside contributors and this was working up until the API change, correct?

Not really. For my GH organization folder, I use a token with repo (write permissions) scope, that was generated from a collaborator user. Everything was working well until GH decided to change the required permissions to fetch data from the repo/collaborators endpoint from write to admin. The pipeline-github-plugin can not fetch collaborators list anymore (using my collaborator user permissions), thus not starting builds.

[andrey-hura]

The issue can be fixed by granting our token the admin permissions, but it is not safe (we don't want our jenkins to be able to change repository settings) and it is not an option in our case.

I can update this request to be a feature request if that is preferable.

[aaronwalker]

@andrey-hura have you tried switch to github app auth credentials which doesn't have this limitation and also has the added benefit of not being tied to a user https://www.jenkins.io/blog/2020/04/16/github-app-authentication/

I can look into what can be done

[andrey-hura]

thank you for the suggestion, but apps is not a case for us either

[andrey-hura]

could it be configurable?:
issueCommentTrigger(regex: "(?sm)^${phraseRegex}.*", allowNonCollaborators: true)
with allowNonCollaborators defaulting to false.

[aaronwalker]

@andrey-hura not a bad Idea.... I'll take a look but PRs also welcome :)

[aaronwalker]

@andrey-hura with the github API change it actually creates an opportunity to provide a way to allow people access to a repo but not automatically giving them access to trigger jobs via comments or PR approval. What about the idea of configurable allow and deny lists. Which could be either users or teams. There could be a global config or be overridden at the trigger level

Thoughts?

[aaronwalker]

@andrey-hura are you able to share a screenshot of the permissions you set for the token as I'm not able to replicate the issue

[sun-mir]

Sorry for the long silence here...
I work with @andrey-hura and created a GitHub support ticket on that date. Their answer:

This issue was caused by a code change to resolve a discrepancy with user access permissions between the API and web UI. A small number of customer have been adversely affected by this change and therefore we've made the decision to roll this change back for the time being.
The rollback is happening soon and should be available later today.
Please accept our apologies for the inconvenience.

So the reported regression with the collaborators endpoint started to work again somewhere during the 16-17th of September.

I think it still makes sense to proceed with the enhancement of configurable access for non-collaborators and admins.

@aaronwalker, let me know if you still need the exact scope of permissions for our access tokens, I can try to get it for you. I'm pretty sure it's the bare minimum: repo -> *

[aaronwalker]

closed by #111