[Gluster-infra] [Gluster-devel] Jenkins accounts for all devs.
mscherer at redhat.com
Fri Jan 22 09:44:47 UTC 2016
Le vendredi 22 janvier 2016 à 14:51 +0530, Kaushal M a écrit :
> On Fri, Jan 22, 2016 at 2:41 PM, Michael Scherer <mscherer at redhat.com> wrote:
> > Le vendredi 22 janvier 2016 à 11:31 +0530, Ravishankar N a écrit :
> >> On 01/14/2016 12:16 PM, Kaushal M wrote:
> >> > On Thu, Jan 14, 2016 at 10:33 AM, Raghavendra Talur <rtalur at redhat.com> wrote:
> >> >>
> >> >> On Thu, Jan 14, 2016 at 10:32 AM, Ravishankar N <ravishankar at redhat.com>
> >> >> wrote:
> >> >>> On 01/08/2016 12:03 PM, Raghavendra Talur wrote:
> >> >>>> P.S: Stop using the "universal" jenkins account to trigger jenkins build
> >> >>>> if you are not a maintainer.
> >> >>>> If you are a maintainer and don't have your own jenkins account then get
> >> >>>> one soon!
> >> >>>>
> >> >>> I would request for a jenkins account for non-maintainers too, at least
> >> >>> for the devs who are actively contributing code (as opposed to random
> >> >>> one-off commits from persons). That way, if the regression failure is
> >> >>> *definitely* not in my patch (or) is a spurious failure (or) is something
> >> >>> that I need to take a netbsd slave offline to debug etc., I don't have to
> >> >>> be blocked on the Maintainer. Since the accounts are anyway tied to an
> >> >>> individual, it should be easy to spot if someone habitually re-trigger
> >> >>> regressions without any initial debugging.
> >> >>>
> >> >> +1
> >> > We'd like to give everyone accounts. But the way we're providing
> >> > accounts now gives admin accounts to all. This is not very secure.
> >> >
> >> > This was one of the reasons misc setup freeipa.gluster.org, to provide
> >> > controlled accounts for all. But it hasn't been used yet. We would
> >> > need to integrate jenkins and the slaves with freeipa, which would
> >> > give everyone easy access.
> >> Hi Michael,
> >> Do you think it is possible to have this integration soon so that all
> >> contributors can re-trigger/initiate builds by themselves?
> > The thing that is missing is still the same, how do we consider that
> > someone is a contributor. IE, do we want people just say "add me" and
> > get root access to all our jenkins builder (because that's also what go
> > with jenkins way of restarting a build for now) ?
> > I did the technical stuff, but so far, no one did the organisational
> > part of giving a criteria for who has access to what. Without clear
> > process, I can't do much.
> The need right now is the ability for some of the developers to be
> able to re-trigger jobs in Jenkins. Access to the builders is not
> required right away (this would also require changes to the builders
Depend how clean you want the access to be. since jenkins is root there,
you can just add your ssh keys to the builders if you can define a new
> What I had in mind was to create 3 groups - admins,
> maintainers, developers.
> Then we configure Jenkins to give admins full
> access, maintainers access to manually trigger and retrigger, and
> developers the ability to retrigger.
Why the difference between maintainers and developpers, ie, why not let
manual trigger ?
> Jenkins can do this with either
> unix groups, using build.gluster.org's groups and users, or via LDAP.
> Since we'd like to move to freeipa later, I thought it'd be better not
> to create more users/groups on build.gluster.org.
But we still miss the "who decide what go in what group".
Also, that's 3 groups for just jenkins, and we already have 23 teams on
github. I am a bit concerned about having more groups than builder for
EL6, and would really see a simpler model access.
Sysadmin, Community Infrastructure and Platform, OSAS
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part
More information about the Gluster-infra