As we migrate more projects to GitLab on git.drupalcode.org, we have discovered improvements to make in the mapping of Drupal.org project maintainers to GitLab’s project members, ensuring that it is a 2-way synchronization.
The next time you update maintainers for your project on Drupal.org, this will update all maintainers’ access in GitLab. Please review project members in GitLab, and under Activity, the Team events. Syncing is now more thorough, so there might be more maintainership and member changes than you expect.
In the next few days we plan to bulk update GitLab project members for all projects that have maintainers with “Maintain issues” on Drupal.org, granting them the project planner role in GitLab. This will enable more access for them to manage issues and merge requests in GitLab.
We reviewed all the mappings and have settled on:
- “Write to VCS” on Drupal.org 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 will keep choices made in GitLab.
- Maintainer in GitLab grants “Write to VCS” and “Administer maintainers,” matching GitLab’s “Administer maintainers” permission on Drupal.org.
- 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.
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.
Removing a maintainer in GitLab will
- If they were the project node author on Drupal.org, assign authorship to another person with “Administer maintainers,” or fall back to Unsupported projects.
- Remove “Maintain issues,” “Write to VCS,” and “Administer maintainers.”
- Not change access to “Edit project” or “Administer releases.”
- If they have no remaining Drupal.org project maintainership roles, completely remove them as a maintainer.
In addition to filling the gaps in the mappings, updates to maintainership in GitLab were missed, we hadn’t implemented a listener for the user_update_for_team webhook. So updating maintainers on Drupal.org will catch up all project member roles in GitLab.
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.
You can find the full details in the issue at #3586519: Migrate maintainers from Drupal.org projects as GitLab members
For any specific implementation questions, please comment on the issue. For general feedback, post to Drupal Slack's #gitlab-issue-feedback channel.
