Hi! The discussion was raised three years ago straight after git migration. You (infra) promised us to take measures to let recruiters add new developers to the gitolite. Can it finally be implemented so we have full control over the proccess? Thanks in advance!
(In reply to Mikle Kolyada from comment #0) > Hi! > > The discussion was raised three years ago straight after git migration. > You (infra) promised us to take measures to let recruiters add new > developers to the gitolite. Can it finally be implemented so we have full > control over the proccess? > > Thanks in advance! I think mgorny has a script, so its mostly just: 1) Generating an identity for git-o-lite that has permissions to update configs. 2) Running the script as that identity via cron every $interval. Then people just add themselves to LDAP and we are done for anything where permissions are sourced from fields in LDAP. -A
I personally don't see a problem with that. The Overlays team members had to have extended permissions (not sure how far extended though), so I don't see why Recruiters wouldn't have them too. Alternatively, if we want to pursue the wider split of responsibilities and having two pair of eyes on every action, then I guess Infra should do all the work on request from recruiters. However, I personally don't think that it is necessary or really helpful to increase Infra workload there.
(In reply to Michał Górny from comment #2) > I personally don't see a problem with that. The Overlays team members had > to have extended permissions (not sure how far extended though), so I don't > see why Recruiters wouldn't have them too. > > Alternatively, if we want to pursue the wider split of responsibilities and > having two pair of eyes on every action, then I guess Infra should do all > the work on request from recruiters. However, I personally don't think that > it is necessary or really helpful to increase Infra workload there. Well, I thonk if recruiters get the access, we will not infra with this work anymore (like it was with CVS).
Ping, lets just add every single recruiter to the @overlays-admin group, not to create the permissions mess
ok, yet another look showed that recruiters will need different acl than overlays admins have
Should be all done now.
