GitLab permissions documentation: https://docs.gitlab.com/ee/user/permissions.html

Developer access was initially chosen by principal of least privilege; it gave people equivalent access as pre-GitLab, and kept the migration scope lower. Now that our use of GitLab features is increasing, there is access which we should allow, such as Manage CI/CD variables. Drupal.org is still the canonical source for projects and maintainers, we should ensure the project metadata set on Drupal.org can’t be overridden. And we also need to understand the scope of new services we provide - can they be abused, such as excessive cost, spam, time spent supporting them? Nothing stands out as a blocker in the additional permissions, need to go through them one-by-one and double check.

Issue fork drupalorg-3196581

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

drumm created an issue. See original summary.

drumm’s picture

Assigned: Unassigned » drumm

This is not as straightforward as we had hoped.

Default branch - the default branch can be changed, which does not trigger a repository synchronization event. The default branch is used very little on Drupal.org, we can reduce our dependency on it. The project Git instructions can be revised to not use the default branch. Otherwise, it is only Drupal.org’s UI to change the default branch. If needed, we could sync the default branch on every push event to keep it in sync.

Maintainers - maintainers can be updated in GitLab, when Drupal.org is the source of truth here. We could block the requests that actually do the updates, like we do for the “leave project” links. This is non-ideal, it would not be obvious why updating the members page doesn't work. We could receive webhook events from GitLab to sync maintainers back to Drupal.org. This is also non-ideal since “Edit project”, “Administer maintainers”, “Maintain issues”, and “Administer releases” access will still be on the project page, and there is no longer one place to manage all access. This would let maintainers decide on granting only GitLab developer access to some members.

Project features and integrations - this is a bigger issue, lots can be changed, including the project name and path.

  • drumm committed 4146ab1 on 7.x-3.x
    Issue #3196581: Handle maintainership updates made in GitLab
    
ranjithraj’s picture

We can work with GitLab team and configure feature flags to disable permissions to change project name and path for maintainers role.

drumm’s picture

Feature flags in GitLab seem to be mostly for testing and rolling out functionality, not long-term changes. I did find Create project-level policies framework for deny, which looks like a good match for what we want, and something already planned by GitLab.

In the meantime, we should be able to do this with some load balancer rules restricting what pages can be accessed. It is very non-ideal, but will work.

  • drumm committed dfd5ce1 on 7.x-3.x
    Issue #3196581: Move hook_project_maintainer_save/remove()...

  • drumm committed dcc9bfb on 7.x-3.x
    Issue #3196581 by drumm: Give project maintainers GitLab maintainer...
KarinG’s picture

👍 I'd love to be able to use Gitlab -> Settings -> Webhooks

Pasqualle’s picture

D.O Maintainer access translates to the 'developer' role in GitLab right now

Finally I understand what is this issue about

drumm’s picture

Status: Active » Reviewed & tested by the community

This bulk update is now running in batches. Code used is:

$repo_ids = db_query('SELECT vr.repo_id FROM {versioncontrol_repositories} vr WHERE vr.name IN (:names)', [':names' => file('php://stdin', FILE_IGNORE_NEW_LINES)])->fetchCol();
$queue = DrupalQueue::get('versioncontrol_repomgr');

foreach (versioncontrol_repository_load_multiple($repo_ids) as $repository) {
  print $repository->name . PHP_EOL;
  $auth_handler = $repository->getAuthHandler();
  $auth_data = $auth_handler->getUserData();
  $project = versioncontrol_project_project_load($repository->repo_id);
  foreach ($auth_data as $uid => &$data) {
    $data['access'] = _drupalorg_git_auth_access($project->project['maintainers'][$uid]['permissions']);
    $auth_handler->setUserData($uid, $auth_data[$uid]);
  }
  $auth_handler->save();
  $queue->createItem([
    'operation' => [
      'forceSyncUsers' => [],
    ],
    'repository' => $repository,
  ]);
}

  • drumm committed 82d7ffb on 7.x-3.x
    Issue #3196581: Add note about managing Git access on git.drupalcode.org
    
drumm’s picture

Status: Reviewed & tested by the community » Fixed

This is now complete.

KarinG’s picture

Awesome! I can see Gitlab -> Settings -> Webhooks now. Thank you!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.