How the FAS and Gitlab groups are synced? Do we need to have them named
same?
Michal
On 04. 08. 23 14:04, Fabian Arrotin wrote:
On 04/08/2023 08:49, Ryan Lerch wrote:
> On Fri, Aug 4, 2023 at 4:41 PM Fabian Arrotin
> <fabian.arrotin(a)arrfab.net> wrote:
>>
>> On 04/08/2023 02:25, Ryan Lerch wrote:
>>> I just would get a discussion started with the process of
>>> semi-formalizing the grouping and naming guidelines for the Fedora
>>> GitLab instance.
>>>
>>> Currently there are a bunch of groups with subgroups in the main
>>> /fedora/ namespace:
>>>
>>>
https://gitlab.com/fedora
>>>
>>> Depending on how we decide to group, some of these may remain there
>>> (or possibly be grouped together in another group) This is however
>>> some repos and groups that i'm not sure what they are or could
>>> probably be moved into some existing groups:
>>>
>>> * Source Git group (
https://gitlab.com/fedora/src) -- not what you
>>> think it only has 4 repos so far
>>> * Fedora Podcast (
https://gitlab.com/fedora/podcast) could possibly go
>>> under marketing maybe
>>> * Packager-Tools (
https://gitlab.com/fedora/packager-tools)
>>> * people (
https://gitlab.com/fedora/people) a private group with
>>> one repo in it
>>>
>>> This might have to be something that we have a meeting to discuss and
>>> figure out a scheme?
>>>
>>> cheers,
>>> ryanlerch
>>
>> Hi Ryan,
>>
>> We more or less discussed that with Kevin in the past and for CentOS
>> groups (all coming from same common IPA infra) I proposed that we used
>> something like :
>> <target>-<project>-<group_name>
>>
>> Let me explain : Assuming that we need to grant the CentOS Automotive
>> SIG access to gitlab, the name in FAS/IPA is :
>> gitlab-centos-sig-automotive-developer
>>
(
https://accounts.fedoraproject.org/group/gitlab-centos-sig-automotive-dev...)
>>
>>
>> Same rule but for openshift/ocp : we need to grant the hyperscale sig
>> access to the openshift CI centos infra :
>>
https://accounts.fedoraproject.org/group/ocp-cico-hyperscale/
>>
>> It's then easier to identify which group has access to what
>> (gitlab/openshift/etc) *while* keeping the existing groups, as IPA
>> supports nested groups (so the ocp-cico-hyperscale group in fact
>> contains the sig-hyperscale group
>> (
https://accounts.fedoraproject.org/group/sig-hyperscale/)
>>
>> At least that's the naming convention we agreed on so that we can also
>> easily identify if that's a fedora/centos group (all the sig-* groups
>> weren't following that naming convention as they were coming from
>> previous FAS and so imported/merged with the fedora groups in IPA, but
>> there was no conflicting group back then)
>>
>
> Oh, i can also definitely get on board with a set scheme for Fedora
> Accounts groups <-> Gitlab Groups naming conventions.
>
> However, the one of the main issues i am noticing with our current
> GitLab setup is that the groups that are being added are being done in
> an adhoc setting.
>
> For example, there are groups for Council and Mindshare (and not yet,
> but i can imagine a FesCO group too) -- should these be grouped
> together under, say a "Governance" Sub group?
>
> cheers,
> ryanlerch
>
Multiple solutions : one can always create new groups and reflect that
at gitlab level (same membership but different group name[s]) and IPA
supports multiple "nesting" levels so you can (in your Governance
example) have one groups containining/nesting multiple other ones
_______________________________________________
infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
To unsubscribe send an email to infrastructure-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedora...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue