Status: Resolved (View Workflow)
All the symptoms are the same as in https://issues.jenkins-ci.org/browse/JENKINS-40652.
I have a repository without a `Jenkinsfile`, there is an user with write access to it that creates a PR from a branch in the same repo and jenkins doesn't pick it up, saying:
Getting remote pull request #6379... Checking pull request #6379 (not from a trusted source) Job name: PR-6379 ‘Jenkinsfile’ not found Does not meet criteria 1 pull requests were processed
If the user created the PR from a branch in his fork, then it works perfectly.
JENKINS-36240 Default repository permission are not considered
Well to confirm the bug as fixed we need to know that the "Admin or Write permissions" trust strategy looks up the details correctly.
The collaborators API end-point would need to have been checked using the api token that your jenkins was using (as the issue with that API is very often Jenkins does not have permission to check the list of collaborators)
OK, I can do that, but what I don't understand is why this only affects PRs created from the same repo (not from forks) since the trust evaluation seems to be for forks, you can always trusts branches in the same repo...
Now all strategies seem to work. Is hard to test this as I don't have new private repos to use, and I don't know if once I tested something in a repo if it becomes "tainted" and then everything I test will work (there is no Jenkinks file in the repo I'm testing though, only PRs with Jenkinsfiles).
I will report back if I find any issues again in the future. Thanks!
OK, I'm doing a test the the "Everyone" strategy, since it seems the more appropriate for an organization that only contains private repos. But just FYI, querying the github API using https://developer.github.com/v3/repos/collaborators/, the user that was considered as untrusted by jenkins was indeed a collaborator.