8000 [JENKINS-36240] Better implementation of getTrustedRevision by jglick · Pull Request #96 · jenkinsci/github-branch-source-plugin · GitHub
[go: up one dir, main page]

Skip to content

[JENKINS-36240] Better implementation of getTrustedRevision #96

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 agre 8000 e to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

jglick
Copy link
Member
@jglick jglick commented Dec 16, 2016

Downstream of jenkinsci/github-api-plugin#11.

@reviewbybees

… precision whether a PR author would have had write access to the origin repo.
@ghost
Copy link
ghost commented Dec 16, 2016

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

We used to retain information about what was trusted;
now this is checked only if and when getTrustedRevision is called.
Copy link
Member
@stephenc stephenc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to wait for the API to be confirmed before we can merge this. Also we may need to retain the old behaviour for tokens that do not have permission to do the permission check

trusted = false; // TODO JENKINS-37608: make this configurable
} catch (HttpException x) {
if (x.getResponseCode() == 403) {
listener.getLogger().format("Not authorized to do a direct permission check of %s on %s/%s; scan token has no access to this repository%n", sourceOwner, repoOwner, repository);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cache this so you don't retry the request for all PRs, also perhaps we should drop back to the previous behaviour if the permission is missing

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cache this so you don't retry the request for all PRs

Not sure why caching would be required; this code should only be run during an actual build of the branch project. We could try to cache 403s per repository × credentialsId, though this cache could become stale for several reasons—different token, perhaps different permissions for a given token, different repository or team settings…

@jglick
Copy link
Member Author
jglick commented Jan 3, 2017

we need to wait for the API to be confirmed before we can merge this

Probably. Or at least figure out how to fall back to earlier behavior in the meantime.

we may need to retain the old behaviour for tokens that do not have permission to do the permission check

AFAIK those would not have had permission to use the old API either.

@jglick
Copy link
Member Author
jglick commented Jan 19, 2017

wait for the API to be confirmed before we can merge this

Or just implement JENKINS-37608 so that the user can configure a fixed behavior for all pull requests. The current implementation is so flawed I see little point in retaining it.

@jglick
Copy link
Member Author
jglick commented Feb 9, 2017

I think what I want this to do is:

  • trust nonforked PRs unconditionally, as it already does
  • for a forked PR,
    • try using the experimental API, and accept the result if it comes in
    • else check a configuration option (at repo or org level) about whether to trust all forked PRs, or none
    • else, if not configured, do not trust it

@stephenc
Copy link
Member
stephenc commented Apr 7, 2017

The functionality of this change will be reviewed after https://issues.jenkins-ci.org/browse/JENKINS-43426 has been delivered

@jglick
Copy link
Member Author
jglick commented May 1, 2017

Indeed this will likely need to be rewritten to use the proposed new API.

@jglick
Copy link
Member Author
jglick commented Jul 17, 2017

Needs to be reworked to offer an alternative to ForkPullRequestDiscoveryTrait.TrustContributors based on the GitHub API which is now official at least on github.com (no idea about GHE status): hub4j/github-api#358

@stephenc
Copy link
Member

@jglick did you see #148?

@jglick jglick closed this Jul 17, 2017
@jglick jglick deleted the repo-user-permission-JENKINS-36240 branch July 17, 2017 18:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0