It was never automated/setup/run... ;)

I think if we do a sync of any group that is the same name in fas and pagure.io... we should really advertise this and make sure everyone knows. I have a feeling it could be unexpected for some groups that just happen to have the same names. Or we could just make it opt in (ie, only those groups people ask us to sync do we sync).

I agree it would be nice to sync our groups (fedora-infra, sysadmin-main, etc).

I will make this configurable and either there will be a list of groups to sync or any group with same name in FAS and Pagure will be synced.

It was never automated/setup/run... ;)

It was also never really meant to be :)

I think if we do a sync of any group that is the same name in fas and
pagure.io... we should really advertise this and make sure everyone knows. I
have a feeling it could be unexpected for some groups that just happen to have
the same names. Or we could just make it opt in (ie, only those groups people
ask us to sync do we sync).

I think automating some groups could be of interest but I wouldn't automate all
the groups, even if they have the same names.
Being able to have a map of fas group -> pagure group to sync could be valuable
and it would allow these groups to have different names if needed.

I started to work on this (PR incoming). But before merging it, I would need to first implement this in Pagure https://pagure.io/pagure/issue/5333, which will probably take some time before it will be available in our infra.

Related PR

I've just announced on the devel list that I wanted to start working on this exact thing without realizing it was already started... great!

I don't understand how pagure groups could have different names than those available from IPA, since login to pagure can only fetch user data from IPA, anyway here are a couple of notes.
It would be nice this toddler to be run also at least for the packager and provenpackagergroup for both pagure.io and src.fp.o. As we're now removing packagers and provenpackagers from regular bases, querying users in those groups and having different results between src.fp.o and noggin can be confusing. It would also solve https://pagure.io/find-inactive-packagers/issue/1449.

Another point I want to raise is that not every IPA user is present in the pagure/src.fp.o database: if they have never logged in, they're not there, so the script must take that into account when it tries to add a new user to a group. Ideally, it should add the new user to the pagure/src.fp.o database, but from a quick look there's no endpoint to do that...

'pagure' is overloaded here.

pagure.io -> has it's own completely seperate groups from the account system. When someone logs in there, no groups are synced from the account system.

src.fedoraproject.org -> uses only groups from account system, syncs them on login.

This work is just for pagure.io as the src.fp.o is synced on each login as @kevin already mentioned.

This work is just for pagure.io as the src.fp.o is synced on each login as @kevin already mentioned.

My point is: users that left Fedora will never login again, so their state will not be updated in src.fp.o. For example, users removed from packagers in the last two cycles are still listed in packagers group within src.fp.o.

I can see what you are trying to achieve here, this work could be probably used for that as the FAS is the source of truth for this toddler

This toddler is now merged and deployed in both staging and production.