Any way to restrict build for non-whitelisted users?

Details

Description

In Github Pull Request Builder plugin, It is possible to create whitelist for which PR build automatically. For non whitelisted users admin must approve that PR to be build. Then comment can trigger build for that PR. Unfortunately it isn't compatible with Pipeline.

So it will be nice to have those functionality on github-branch-source-plugin.

Activity

This requires the concept of interesting branches and revisions to be introduced to the SCM API plugin.

Once that is present then you should be able to mark commits from non-whitelisted users as non-interesting and hence the branch-api plugin suppress automatic building of those commits

In the interim, the best workaround you can use is to leverage trust for non-origin forks. Builds from non-trusted users will build using the Jenkinsfile from the target branch. Then in your target branch Jenkinsfile you can have the very first thing be a check against the whitelist of users and abort the build if the user is not in the whitelist (you'd probably like to have JENKINS-27092 to allow you to do this with the error step so you could get the natural NOT_BUILT status... but it's not critical if you just need to ensure that the whitelist is enforced)

Stephen Connolly
added a comment - 2017-07-27 10:30 This requires the concept of interesting branches and revisions to be introduced to the SCM API plugin.
Once that is present then you should be able to mark commits from non-whitelisted users as non-interesting and hence the branch-api plugin suppress automatic building of those commits
In the interim, the best workaround you can use is to leverage trust for non-origin forks. Builds from non-trusted users will build using the Jenkinsfile from the target branch. Then in your target branch Jenkinsfile you can have the very first thing be a check against the whitelist of users and abort the build if the user is not in the whitelist (you'd probably like to have JENKINS-27092 to allow you to do this with the error step so you could get the natural NOT_BUILT status... but it's not critical if you just need to ensure that the whitelist is enforced)

Brian J Murrell
added a comment - 2018-08-27 19:13 The proposed solution doesn't really implement what the OP is requesting.
He doesn't want to outright refuse to build PRs from non-whitelisted users but wants them to be sent to an approval queue where he can release them to be built or reject them.
This kind of security is really quite important as without it, it allows all-comers to execute any code they want on your builders.

100% agree. The GHPRB plugin which appears to have now been deprecated in favor of github-branch-source-plugin has a major feature gap that appears to have been misunderstood here. This is a blocker issue for us on migrating away from GHPRB, and from a security perspective we're currently in a less than desirable position since GHPRB seems to presently have security issues.

As a maintainer of an OSS project running a self-hosted Jenkins instance for the community, I want to build all PRs by those who are trusted contributors (which may be more than just those with merge rights) automatically. For those who are not trusted, the PR build needs to be authorized via PR comment by a trusted user before it is built. This should support Multibranch pipeline style jobs via Jenkinsfile so that the build process itself may be updated by untrusted OSS contributors. This approval pipeline/step/check is critical because you must protect against malicious PR modifications of a Jenkinsfile.

Jonathan Gray
added a comment - 2018-09-22 18:21 100% agree. The GHPRB plugin which appears to have now been deprecated in favor of github-branch-source-plugin has a major feature gap that appears to have been misunderstood here. This is a blocker issue for us on migrating away from GHPRB, and from a security perspective we're currently in a less than desirable position since GHPRB seems to presently have security issues.
As a maintainer of an OSS project running a self-hosted Jenkins instance for the community, I want to build all PRs by those who are trusted contributors (which may be more than just those with merge rights) automatically. For those who are not trusted, the PR build needs to be authorized via PR comment by a trusted user before it is built. This should support Multibranch pipeline style jobs via Jenkinsfile so that the build process itself may be updated by untrusted OSS contributors. This approval pipeline/step/check is critical because you must protect against malicious PR modifications of a Jenkinsfile.

Removing myself as assignee. My current work assignments do not provide sufficient bandwidth to review these issues and in the majority of cases I am only assigned by virtue of being the default assignee. For the credentials-api and scm-api related plugins I have permission to allocate time reviewing changes to these APIs themselves to ensure these APIs remain cohesive, but that can be handled through PR reviews rather than assigning issues in JIRA

Stephen Connolly
added a comment - 2018-10-31 09:59 Removing myself as assignee. My current work assignments do not provide sufficient bandwidth to review these issues and in the majority of cases I am only assigned by virtue of being the default assignee. For the credentials-api and scm-api related plugins I have permission to allocate time reviewing changes to these APIs themselves to ensure these APIs remain cohesive, but that can be handled through PR reviews rather than assigning issues in JIRA

Brian J Murrell
added a comment - 2019-02-21 05:40 Stephen Connolly Your workaround suggestion in the first comment along with Jenkinsfile 's input step could lead to a more useful workaround.
The only thing that is missing is the ability for a Jenkinsfile to determine the "trust"ability of the PR. Is that at all possible?

It's also a human interfacing issue too. Once the concept of trust apart from committership/ownership exists, the existing solution uses the PR itself as the CI interface to permit/retry/whitelist the build/submitter.

Jonathan Gray
added a comment - 2019-02-21 07:17 It's also a human interfacing issue too. Once the concept of trust apart from committership/ownership exists, the existing solution uses the PR itself as the CI interface to permit/retry/whitelist the build/submitter.