[JENKINS-66661] Fix fallback behavior of Fork PR trust criteria

[Dohbedoh]

Description

JENKINS-66661: The "Collaborators" and "From users with Admin or Write permission" trust strategies of the PR from Fork traits are breaking Indexing / event mechanism / Jenkinsfile retrieval in cases where the request fails with 401 | 403 | 404.
Instead of failing the entire scan, the trust check should return that the revision is not trusted.

Submitter checklist

• Link to JIRA ticket in description, if appropriate.
• Change is code complete and matches issue description
• Automated tests have been added to exercise the changes
• Reviewer's manual test instructions provided in PR description. See Reviewer's first task below.

Reviewer checklist

• Run the changes and verify that the change matches the issue description
• Reviewed the code
• Verified that the appropriate tests have been written or valid explanation given

Documentation changes

• Link to jenkins.io PR, or an explanation for why no doc changes are needed

Users/aliases to notify

[Dohbedoh]

ping @jenkinsci/github-branch-source-plugin-developers

[jtnord]

Personally I am against this change as is.

If the repository collaborators can not be obtained then the job should fail fast not hide the fact in a log message that no one is looking at.

People have setup the job with the expectation that it would test their Jenkinsfile changes in a PR -

If they want everything to be treated as non trusted then they should actually set the trust to "no one".

This would lead to PRs from maintainers passing when they should fail and then a potentially broken master branch.

I would go so far as to say the previous fix in this area was also incorrect.

if a user is wanting to be able to trust some users (not all and not none) then we should obey this and if we can not should not silently ignore the fact and continue (no one looks at logs unless something breaks!)

IN other words the correct "fix" for me would be to catch the exception and throw a more detailed one saying your credentials "do not have access to query for collaborators - you can either change your scan credential or change the trust model to NO-ONE"

[jglick]

(also see jenkinsci/scm-api-plugin#180)

[Dohbedoh]

Adjusted the behavior to the following:

• on PR retrieval (org scan / branch indexing / PR event) the PR is skipped if the trust check fails with an exception
• on PR revision retrieval (get the Jenkinsfile when building a PR) the retrieval fails if the trust check fails with an exception

[Dohbedoh]

pinging maintainers @dwnusbaum @jeromepochat @rsandell

[jtnord]

on PR retrieval (org scan / branch indexing / PR event) the PR is skipped if the trust check fails with an exception
on PR revision retrieval (get the Jenkinsfile when building a PR) the retrieval fails if the trust check fails with an exception

#711 (review) appears to still stand.
The org scan should not behave differently to the retrieval of code, that appears to just be bumping the issue down the line?

If you really do want to ignore and continue in my view there needs to be something obvious to users. I would say an AdministrativeError but this error should be visible to whomever can configure the org folder job (and ideally whoever can see all the children - as they are the impacted users)

[Dohbedoh]

The org scan should not behave differently to the retrieval of code, that appears to just be bumping the issue down the line?

It is Branch Indexing. I think it should. Branch Indexing may scan other branches, tags, PR from origin and if the processing of one of them interrupts everything (while the other should have worked) then this is a resilience problem.

There might not be any forked PR at the time you create the Multibranch and you may realize the problem only when one is created.

If you really do want to ignore and continue in my view there needs to be something obvious to users.

It would still be visible to the users concerned (the dev that don't have their PR processed) but at least other users (working on branches, and relying on tags and origin PRs) are not. And if the problem is raised, a quick look at branch indexing would also confirm it. An exception in the branch logs is almost as obvious as a broken branch indexing. In both cases, you need to go and have a look at it explicitly.. And this is another problem.