|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
cforce: If you don't like the design of Role Strategy plugin, don't use it. It sounds like project-based matrix auth or the commercial Jenkins Enterprise plugin Role Based Access Control is a better fit for your needs. Besides, this has nothing to do with this issue or this plugin – maybe ask the jenkins-users mailing list for help instead?
Larger Jenkins instances also usually don't allow running any jobs on the master node. Just set up separate build nodes and only use the main Jenkins server as fancy UI and data storage. Then no builds have direct access to Jenkins config and data by escaping their $WORKSPACE.
Regarding isolation, Jenkins Enterprise offers some solutions here (e.g. Folders/Folders Plus plugins that allows restricting build nodes (slaves) to certain authorized project folders, so you can have org1-slave and org2-slave, and nobody configuring org1 jobs can get them to execute on org2-slave, isolating temporary workspaces).