Gitlab groups and user management

Ticket: FAL-1826

So we currently have toplevel groups in gitlab labelled dev, client, accounting, documentation. One of the reasons is that all members have access to the dev group, only core members, have access to client, etc.

I’m thinking that it may be a good idea to create newcomers, core, etc. groups, and use them like we do for our github teams. It would add a nice symmetry with github, and make the groups user management clearer. Then for the dev, client, etc. groups, we can add group access - eg. opencraft/newcomers would have maintainer access to opencraft/dev, but not to opencraft/client.

Also, what are the semantics for a member being a member of the root opencraft group?


@swalladge Good idea, now that we move more and more to gitlab, it does make sense to have a better approach for newcomers vs core. :+1:

Not sure what you mean by semantics, but that’s pretty much the equivalent of “admin access” currently. The people in that group are the “general” managers (Braden and me), plus the recruitment cell managers who need the right to onboard newcomers.

NB: Also, maybe we could make this thread public? There isn’t anything that needs to be confidential here? Same thing for FAL-1828 Improving forum user management actually

Thanks for clarifying that @antoviaque. :slight_smile:

Sure, we can make this and the other public now.

1 Like

Do we need the Accounting group on gitlab? It seems that it only contains the public accounting app repository - maybe that can be moved to the dev group?

@swalladge If we would have one and we can assign the relevant people there, that would make the PR reviews and other stuff easier in the future if we start actively working on that (I think, but I may be wrong).

Thanks for this @swalladge. I think that when we started with GitLab, it didn’t let you assign Groups as members of groups, so we were kind of forced to set things up this way. I was annoyed by always having to add and remove users from multiple groups. I guess at some point they implemented the feature of adding groups to groups, so now we can do it this way which makes way more sense :slight_smile:

I would even suggest we go further and now remove the dev and docs groups, and just combine their repositories into the top level opencraft project, but it’s probably too late / inconvenient to do that at this point.

1 Like

@antoviaque created it recently, so I guess he wanted to keep it separate from the dev group and grant access only to people who will work on it. @antoviaque, could you confirm?

In addition there were discussions and a code draft to move the deployment to GitLab CI, so that the software be automatically deployed to production after successfully merging a MR. This happens in some of the accelerated projects. If this is done for the accounting project, then the GitLab accounting group would decide who has the right to deploy to production. But I personally think we don’t need to deploy the billing system automatically; it would be safer if we deploy it manually (ansible, SSH). That’s another discussion.
For now I’d leave the accounting group as it is, to limit push access, as mentioned in the first paragraph.

Sorry for missing the ping here, it looks like my filtering rule for the forum needed to be updated. But yes, that’s correct.

1 Like