[Jenkins-infra] User management on jenkins-infra Github organisation?

Kohsuke Kawaguchi kk at kohsuke.org
Thu Jan 3 20:27:09 UTC 2019

I'm a big fan of "getting out of the way between people and what they want
to do" and our ops resources is precious and should be focused on strategic
things as much as possible.

IIUC, what you are proposing is very much in line with that. So I think
it's great.

On Thu, Jan 3, 2019 at 5:47 AM Olblak <me at olblak.com> wrote:

> Hi Everybody,
> First of all I wish you a happy new Year.
> I am looking for feedback for the best way to manage user permission on
> the Github jenkins-infra organization.
> The current process is "someone" open a jira ticket requesting for
> specific repository permission like INFRA-1925
> <https://issues.jenkins-ci.org/browse/INFRA-1925> and then a
> jenkins-infra admin validate and grant that permission.
> While I think opening a jira ticket is still important for visibility,
> only few people can grant organization access and so It can take a lot of
> time between the moment the permission is requested and approved and it's
> time consuming to verify if a request is legitimate or not.
> So I am wondering the best way to delegate that decision to SIG
> maintainers without compromising the organization.
> Therefore I suggest the follow approach:
> One parent team based on the SIG group name with the same maintainer than
> the sig group defined from jenkins.io/sig
> <https://jenkins.io/sigs/platform/> and with no repository permission
> configured at that level is allowed to configured and managed sub teams.
> And then each child teams is configured with specific members and specific
> repositories permission.
> The reason why the parent team shouldn't configure repository access, is
> because child team inherit parent repository permission.
> An example is java11-support
> <https://github.com/orgs/jenkins-infra/teams/java11-support> where
> baptiste and oleg have admin permission on java11-support including child
> teams. java11-support has two child teams, java11-support-maintainer and
> java11-support-reviewer, with respectively write and read permission on
> different repositories. This approach delegates permission management to
> java11-support maintainers.
> Remark: A maintainer can only add repository that he has access to the
> team he managed.
> Another element that regularly come back and doesn't make sense to me is
> that we have teams which only have read permission in order to make PR
> reviews but those reviews can't be taken into account when we want to merge
> Pull request with branch protection enabled, as those reviewers need write
> permission.
> So I wonder if we really need those read only teams .
> More information here
> <https://help.github.com/articles/about-required-reviews-for-pull-requests/>
> Cheers,
> ---
> -> gpg --keyserver keys.gnupg.net --recv-key 52210D3D
> ---
> _______________________________________________
> Jenkins-infra mailing list
> Jenkins-infra at lists.jenkins-ci.org
> http://lists.jenkins-ci.org/mailman/listinfo/jenkins-infra
Kohsuke Kawaguchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.jenkins-ci.org/pipermail/jenkins-infra/attachments/20190103/ca20aef5/attachment.html>

More information about the Jenkins-infra mailing list