Currently everyone must get push access to each individual issue fork repository. This workflow was originally set up as a "speed bump" to discourage mass-updating all issue forks.

As we move toward moving issues to GitLab, #3250923: GitLab Collaboration Workflow: Enable GitLab issues and forking into the 'issue' namespace, with shared access across the community, the issue fork workflow will be similar. GitLab does not allow injecting UI elements, so we can’t put the same button on the GitLab issue page. We could have a bot people can summon to get access, but that would be clunky and noisy. Or we could keep our own UI on Drupal.org to get access, which would be clunky.

Instead of trying to keep this functionality, we can remove the need for it. Issue forks are in the https://git.drupalcode.org/issue group. We can give everyone with group-level access and that will allow access to every issue fork.

Tasks

  • See what happens for email notifications when someone is added to the group. Turn off notifications if needed & possible.
  • ✅ done - Write MR which automatically adds people to the group when they get a new git.drupalcode.org account.
  • 🔄 in progress - Write bulk update to add existing people top the group.
  • Add integrity check for everyone being in the group,
  • Write MR to remove “Get push access” button and related functionality.

Deployment

  1. Deploy changes to add new git.drupalcode.org users to the https://git.drupalcode.org/issue group.
  2. Bulk update to add all existing users to the issue group.
  3. Deploy changes to remove “Get push access” button and related functionality.

Issue fork drupalorg-3313979

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:

About issue forks

Comments

drumm created an issue. See original summary.

nick_vh’s picture

nick_vh
he/him
Location Ghent
commented

Alternatively we could see if we can enhance this functionality: https://docs.gitlab.com/ee/user/project/merge_requests/allow_collaborati...

If forks have this enabled, and we add an option to allow this for also people with the reporter role, it might also solve your problem instantly? it does mean you need to have all users of d.o in GitLab, but I think you were planning to do that already?

fjgarlin’s picture

fjgarlin commented
Related issues: +#3317536: Allow modules to perform actions on sync

@drumm - will the above be enough for our case?

As an alternative, I'm adding a hook on versioncontrol_gitlab module here #3317536: Allow modules to perform actions on sync that would allow us to perform additional sync tasks.
I will follow up with an MR here too.

fjgarlin opened merge request !135

fjgarlin’s picture

fjgarlin commented
Status: Active » Needs review
drumm’s picture

drumm
he/him
Location NY, US
commented

@nickvh - this is for commit/push access, so I don’t think the reporter role helps.

It is also for every fork of every project, so if GitLab’s future configurable roles do help, we’d be doing the same general syncing, just with a different role and group.

The idea is to preserve the ability for multiple people to collaborate on code. With patches, I can pick up a patch and make progress on it, regardless of who created the patch. The same should be true of code in forks.

nick_vh’s picture

nick_vh
he/him
Location Ghent
commented

@drumm, I think we're thinking the same - but probably I wasn't explaining or expressing it correctly. I'll keep you informed from the GitLab side if anything changes there towards that end. :-)

  • drumm committed 4aa2219 on 7.x-3.x authored by fjgarlin 
    Issue #3313979: Give everyone with git.drupalcode.org commit access to...

drumm opened merge request !141

drumm’s picture

drumm
he/him
Location NY, US
commented
Issue summary: View changes

The initial deployment is done and users are being bulk added to https://git.drupalcode.org/groups/issue/-/group_members with this script:

$group_ids = variable_get('versioncontrol_gitlab_namespace_ids', []);
if (empty($group_ids['issue'])) {
  return;
}
$group_id = $group_ids['issue'];
$client = versioncontrol_gitlab_get_client();

$gitlab_user_ids = db_query('SELECT gitlab_user_id FROM {versioncontrol_gitlab_users} vgu INNER JOIN {users} u ON u.uid = vgu.uid')->fetchCol();
foreach ($gitlab_user_ids as $gitlab_user_id) {
  print $gitlab_user_id . ' ';
  try {
    $user_in_group = !empty($client->groups()->member($group_id, $gitlab_user_id));
  }
  catch (Exception $e) {
    $user_in_group = FALSE;
  }

  if ($user_in_group === FALSE) {
    // '30' is “Developer access” https://docs.gitlab.com/ee/api/members.html
    $client->groups()->addMember($group_id, $gitlab_user_id, '30');
  }
}

The INNER JOIN is due to #3319007: Delete users from versioncontrol_gitlab_users on user deletion

drumm’s picture

drumm
he/him
Location NY, US
commented

I also discovered #3319008: Enable notifications for https://git.drupalcode.org/issue when making sure we weren’t sending 61,000 emails from this.

  • drumm committed e0decfd on 7.x-3.x 
    Revert "Issue #3313979: Give everyone with git.drupalcode.org commit...
drumm’s picture

drumm
he/him
Location NY, US
commented
Assigned: Unassigned » drumm
Status: Needs review » Closed (won't fix)

This has not worked out at all. Will go back to #3250923: GitLab Collaboration Workflow: Enable GitLab issues and forking into the 'issue' namespace, with shared access across the community for figuring out a different plan.

drumm closed merge request !141