-
Notifications
You must be signed in to change notification settings - Fork 371
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[JENKINS-66661] Fix fallback behavior of Fork PR trust criteria #711
base: master
Are you sure you want to change the base?
Conversation
ping @jenkinsci/github-branch-source-plugin-developers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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"
(also see jenkinsci/scm-api-plugin#180) |
Adjusted the behavior to the following:
|
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
Reviewer checklist
Documentation changes
Users/aliases to notify