+1. In my config this makes PR builds useless, because they're always building master.

+1.. This is pretty much a blocker for us. We were right in the middle of migrating to using Jenkinsfiles and multibranch pipelines when we encountered this.

Basically, if you don't already have a Jenkinsfile merged to the base branch (say your PR contains a WIP Jenkinsfile, like in our case), then Jenkins throws an error stating no Jenkinsfile found. It's only loading trusted files from the base branch which at this point doesn't contain a jenkins file, so nothing runs.
Here are some steps to reproduce that i posted in another comment:

Using a multibranch pipeline project with the latest SCM API 2.0 release, we have also noticed PR's from contributors getting flagged as untrusted sources.. Despite the PR author having admin privileges as a contributor and is the member of a Github team that also has Write permissions for the repository.

To test this..

Build settings:
[x] Build origin PRs (unmerged head)

1. Submit a PR to origin base branch with changes to the Jenkinsfile (add an echo or something)
2. Open up a PR and scan the repository.
3. Observe, In the scan log, the source will appear untrusted
4. Jenkins will checkout the base branch instead
5. The base branch Jenkinsfile is executed

The repository scan log looks like this:

    Checking pull request #1817
    (not from a trusted source)
    Job name: PR-1817
      ‘Jenkinsfile’ found
    Met criteria

Jenkins PR job log:

Loading trusted files from base branch dev at {commit} rather than {commit}

I have the same issue. Linking https://issues.jenkins-ci.org/browse/JENKINS-37931

This issue predated SCM API 2.0.

FWIW the relevant plugin code is here

It's definitely a bug. I built the latest github-branch-source-plugin (2.0.1-beta-2) and all dependencies.

I inserted logger statements inside the

getTrustedRevision

as:

            PullRequestSCMHead head = (PullRequestSCMHead) revision.getHead();
            listener.getLogger().format("head source owner: " + head.getSourceOwner() + "%n");
            listener.getLogger().format("head target repo owner: " + head.getTargetRepo().getOwner() + "%n");
            listener.getLogger().format("collaboratorNames: " + collaboratorNames + "%n");
            listener.getLogger().format("collaboratorNames empty: " + collaboratorNames.isEmpty() + "%n");
            if (fork && collaboratorNames == null) {

and during a build of a PR the output is:

Connecting to https://api.github.com using myoung34/******
head source owner: _redactedowner_
head target repo owner: GHUser@2e80c396[login=_redactedowner_,location=Nashville, TN,blog=http://www._redactedowner_.com,email=<null>,name=_redactedowner_,company=<null>,followers=0,following=0,url=https://api.github.com/users/_redactedowner_,id=1073954]
collaboratorNames: [...snip..., myoung34, ...snip...]
collaboratorNames empty: false
Loading trusted files from base branch master at 784081c38d601c3602e76ba10394e8839333e22b rather than 90f516ebf3af5d9b2abfc6e8e6b2699a73b2ca3f

Even though I'm a collaborator it's still saying that it's untrusted. The if condition is not being hit during this time, so it's not re-checking. I'm making some bugfixes now and hopefully the upstream owners will accept them when finished.

Fixed code in PR: https://github.com/jenkinsci/github-branch-source-plugin/pull/109

Provisionally marked as SCM 2.0 Upgrade Fallout until we determine otherwise.

https://github.com/jenkinsci/github-branch-source-plugin/pull/114 is a minimal fix of the regression for merging into the 2.0.x upgrade fallout

myoung34 I have created https://issues.jenkins-ci.org/browse/JENKINS-41522 to track the other changes in https://github.com/jenkinsci/github-branch-source-plugin/pull/109

stephenconnolly thanks so much!

Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSource.java
http://jenkins-ci.org/commit/github-branch-source-plugin/93d81cf26e8b46afdedf91c617c342b278257b4b
Log:
JENKINS-40652 Minimal fix for trusted revision

Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSource.java
http://jenkins-ci.org/commit/github-branch-source-plugin/5607e401b9ac4b3f02b1c44e5b967630ad7b90b0
Log:
Merge pull request #114 from stephenc/jenkins-40652

JENKINS-40652 Minimal fix for trusted revision

Compare: https://github.com/jenkinsci/github-branch-source-plugin/compare/df02d731c5c1...5607e401b9ac

Marking this as fixed in github-branch-source-plugin 2.0.1-beta-5 but there are likely follow-up side issues being tracked in JENKINS-41522

Code changed in jenkins
User: Stephen Connolly
Path:
src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSource.java
http://jenkins-ci.org/commit/github-branch-source-plugin/bb18410cff11efd7b21ccf4c55dfb6719bb61c12
Log:
JENKINS-40652 Late fix

scm-api-2.0.2
git-2.6.4 or git-3.0.4
branch-api-2.0.2
bitbucket-branch-source-2.0.2
github-branch-source-2.0.1
cloudbees-folder-5.17
workflow-multibranch-2.11