You can do this by doing a PR from a branch in the same repo - which I think is a better way to honour the intent of the security model of github. Right?

I found that Jenkins use merged Jenkinsfile if PR owner is contributor.
When I opened this issue, I was organization admin, but was not contributor.
this issue was not valid. sorry!

This seems to be an issue, or is poorly documented.

I'm currently a member of the stratasan organization: https://github.com/stratasan
I'm a member, but on a private repo I'm an Admin with all permissions, but I always get:

Loading trusted files from base branch master at 096b02cbb8144a042bd6a5519eac8ccd6cd8e39f rather than e03a3ebc1c4584f16757ac4f80856b4c905bb28a

We have protected branches (require status checks) on master, so I cannot push there, but I have permissions to all other branches.
It's also a PR from a branch within the same upstream (not a fork)

Even if you are an administrator, you must be listed here.
https://github.com/ORGANIZATION/REPO/settings/collaboration

I too have problems with this.

I am in fact listed under collaboration. I have write-access to the repository as a whole through several policies, and I have tried to add my user directly to repo as a collaborator. Both branches in the PR are in the same repo, and I can write to both.

I still get the error

Ditto

I am an admin of the organization on github, member of both 'members' and 'admin'
On the private repo both of those groups have write access.
The PR is on the same origin as the branch to merge into.
I'm listed as collaborator on that repo.

I still get the error.

The bigger issue is that all of these tickets say "you need to be a collaborator". Outside of the fact that being a collaborator still produces the issue, that statement should not be the only way to do this, it should be the minimum.

According to the docs (https://go.cloudbees.com/docs/cloudbees-documentation/cje-user-guide/):

(such as pull requests filed by people not authorized to push to the main repository

And the docs here (https://go.cloudbees.com/docs/support-kb-articles/CloudBees-Jenkins-Enterprise/Why-Jenkinsfile-changes-Are-Not-Reflected-in-PR-Build.html):

Jenkins handles it that way: when changes to the Jenkinsfile are committed to a PR , Jenkins asks GitHub whether the PR author has the permission to push to the origin repository, if yes he is trusted, otherwise he is not.

These are not true based on what we're being told.

What were told about being a collaborator means that admins/members of an org cannot build PR's without extra steps (collaborator per all the replies). This is not effective.
As an admin, we add a new user, put them in a group and let them do their thing. This is an equivalent trust. having to add them as a 'collaborator' on every repo is a pain and prone to mistake. Say we have 100 repos and add a new member or admin. We must go to each repo (or even at the org level but I dont think you can be labeled a collaborator there - only per repo) and add them there too. Forgetting to do that (which everyone will since this documentation is hard to find and not standard practice) means that someone will open a PR to change the Jenkinsfile and it will use the base branches with a single line warning in the build. That line is very easy to miss, so it will get merged and possibly break the next builds because of a syntax error.

According to the docs, asking github whether they can push to the origin is good, but requiring them to be a collaborator is not.

As an admin, I have access to push to that repo so i should be able to use my Jenkinsfile.
As any member with org permissions (member, etc) I have access to push to that repo because the PR is on the same origin as the base branch, so this alone is enough to trust it, group permissions or not. You cannot create a PR from two branches without write access to that origin, so this alone should be enough to use the Jenkinsfile.

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

Probably a duplicate of JENKINS-40652, just an accidental regression.

The more general issue of nuanced behavior is JENKINS-36240, which I have a fix for but it relies on experimental APIs.