Migrate maintainers from Drupal.org projects as GitLab members

Updated issue description.

This might be a duplicate of #3262293: Grant GitLab “reporter” access to project maintainers with “edit project” or “maintain issues”

We should do a bulk update of all projects if we change the mapping of Drupal.org project maintainership roles to GitLab project maintainer roles.

We might not need to do a bulk update if we integrate this with the issue migration. We'd only need to run a separate command for the ones already migrated.

Ready for review. If a user is already a member on the GitLab repository, it won't do anything, and if it isn't, it will be added with the right level of access.

Tested on dev copies:
- https://gitlab1.code-dev.devdrupal.org/project/config_notify/-/project_m...
- https://fjgarlin-drupal.dev.devdrupal.org/node/3114688/maintainers

I tested this in isolation (drush command to migrate maintainers) and also as part of migrating a project (as the same function is being called).

So, after this is merged:
- drush drupalorg_gitlab:migrate-project-issues PROJECT_NAME migrate will take care of the maintainers too.
- drush drupalorg_gitlab:migrate-maintainers PROJECT_NAME will do just the project maintainers.

If we want to do all the projects that we have already migrated, we can get a list running drush drupalorg_gitlab:get-migrated-projects (or from the opt-in issue).

This is fantastic and will help for the next round of projects migrated 🙏

Should we grant any access to people with “manage releases” or “update project” access on Drupal.org? Should they have “Guest” or higher in GitLab?

I think no, since those are specific to things you will continue doing on Drupal.org.

And we should update the text on https://www.drupal.org/node/{project nid}/maintainers, adding to

“Write to VCS” grants the GitLab project developer role. Having both “Administer maintainers” and “Write to VCS” grants the GitLab project maintainer role.

Changed the text to add the new option and also addressed the feedback in the MR.

Retested with multiple projects via the Drupal command. One question in the MR with might not need action (in that case fully ready for review).

Since this is a big permissions change, we are triple checking the mappings. The mappings are now in a single code comment:

• “Write to VCS” grants the GitLab project developer role.
• Having both “Administer maintainers” and “Write to VCS” grants the GitLab project maintainer role.
• “Maintain issues” grants the GitLab project planner role.
• Other Drupal project maintainership roles are not synced.

Syncing is two-way, so that saving maintainers in Drupal keeps choices made
in GitLab.

• Maintainer grants “Write to VCS” and “Administer maintainers,” matching GitLab’s “Administer maintainers” permission.
• Developer grants “Write to VCS” and removes “Administer maintainers.”
• Planner grants “Maintain issues” and removes both “Write to VCS” and “Administer maintainers.”
• Reporter and Guest remove “Maintain issues,” “Write to VCS,” and “Administer maintainers.”

Reporter is very similar to Planner, however it acts the same as guest for maintainership mapping. This preserves access when flipping between setting permissions in GitLab or Drupal. Access to “Maintain issues” in Drupal is mostly irrelevant with issues migrating.

Previously updates to maintainership in GitLab was missed, we hadn’t implemented a listener for the user_update_for_team webhook.

Maintainer in GitLab previously did not grant “Administer maintainers.” It should because in GitLab, it allows the Manage project members permission, so it is a direct mapping.

Once all issues are migrated, “Maintain issues” will be removed from Drupal, and GitLab itself will be the only way to manage access below Developer.

I’m not sure this is the right place

drumm had mentioned that GL members are synced to d.o

I had seen *some* of the GL reporter members I added show up on my d.o project maintainers list

I ended up removing many of them in GitLab but left a few

Those do not show up in d.o

:shrug:

I’d prefer GL reporters not show up on d.o, so it’s fine, but contradicts what I understood from drumm on the syncing feature

https://www.drupal.org/project/ai_context

Previously updates to maintainership in GitLab was missed, we hadn’t implemented a listener for the user_update_for_team webhook.

That’s a big factor in the GitLab → Drupal syncing being spotty.

I see two remaining edge cases:

“Administer maintainers” without “Write to VCS” in Drupal: If someone is in that state, and their membership is updated in GitLab to a level below maintainer, they will lose “Administer maintainers.” I suspect this combination might be somewhat common for an organization account to own the project, but not push code. We do have other barriers in place for self-declared organization accounts to not be able to push commits; so it is okay for an organization account to have “Write to VCS,” they still aren’t allowed.

Being removed from a project in GitLab: Anyone can leave a project at any time in GitLab, there’s a leave project option in the UI. As far as Drupal.org is concerned, this is the same as another maintainer removing you.

Long ago, we set that up so that if you are the project node author, and you leave/are removed in GitLab, node authorship goes to another person with “administer maintainers” or, if there are none, the unsupported projects user.

We’re not mapping “edit project” or “administer releases”, so regardless of node ownership, you currently remain with those. I think it makes sense to remove those too. I could also be convinced to not touch that part now.

Re the edge case above.

I think that when removing from GitLab:
- If the user has "edit project" or "administer releases" on Drupal, leave it.
- If it doesn't, then remove the user.

Otherwise it might be confusing the 2-way syncing and it'll leave residual maintainers without any effective permission.

I’ve closed that last edge case and am deploying this.

We should wait on any bulk updates for a day or two so people have a chance to find any bugs we missed.

This is now deployed and we published some details at https://www.drupal.org/drupalorg/blog/improvements-to-drupalorg-project-...

Leaving this issue open for the upcoming bulk update.