Kirill Merkushev added a comment - 2017-01-31 12:42 seems its not a problem of github-plugin (it does nothing with jenkinsfile and PRs)

Stephen Connolly added a comment - 2017-02-01 10:10 Both of these are intended behaviours. There are improvements to the behaviour planned under JENKINS-36240 Currently, the github branch source attempts to differentiate between pull requests from users who have permission to commit directly to the origin repository and pull requests from randomers on the interwebs creating drive by PRs. The heuristics for detecting whether a given GitHub user is a collaborator can depend on the permissions that were granted to the API token used for scanning, so where that fails, the only PRs that can be assumed "safe" are those from the origin repository itself. JENKINS-36240 proposes to use a new (experimental) API from GitHub that will enable the easier test of asking GitHub "Hey is user jrandomerfromtheinterwebs allowed to commit directly to myorg/trusted-repo" So the plugin will then be able to decide if the PR is trusted or not trusted. When the PR is trusted (i.e. currently if from either an origin repo or from a user listed in the list of collaborators reported to the API token - which is known not to be the full list in a lot of cases) then the Jenkinsfile from the PR will be used. When the PR is not trusted then the Jenkinsfile will not be used, instead the Jenkinsfile from the target branch will be used and if that is missing, so be it. I have created JENKINS-41616 for the component of this request that is a legitimate bug, though not the bug you reported! Thank you very much for this report, as it has identified a bug