Skip to content

Migrate suggested_reviewers_bot to per-organization calls (OR delete the bot)

Context

The Users::Internal module handles users that were previously considered "instance-wide" or "cluster-wide," i.e. there is only one of this user for the entire GitLab installation that is directly referable within GitLab code. Per &18745 , we need to migrate all cluster-wide internal bot users to instead use per-organization internal bot users. This is necessary for Cells and Protocells, to ensure that each user belongs to a single organization and that no user has permissions outside of that organization. This will also allow things like bot comments and issues to be migrated across Cells when an organization is moved, since the associated user is moved along with it.

Note that provisioning and referencing per-organization internal bot users is controlled by a per-organization feature flag. Once new code is deployed for the user type, no behavior will change immediately. Rollout is per-organization and controlled in this issue: #547109

Goal

This issue covers the migration of suggested_reviewers_bot

Proposal 1: delete the bot

This bot is no longer needed and can be deleted from the codebase.

Proposal 2: migrate the bot

Current code:

# legacy calls
Users::Internal.suggested_reviewers_bot

After this issue is complete:

# find the appropriate organization for the action being taken by the suggested_reviewers_bot
my_organization = group.organization || project.organization || user.organization || ::Current.organization
Users::Internal.for_organization(my_organization).suggested_reviewers_bot

# or
my_organization_id = user.organization_id || group.organization_id
Users::Internal.for_organization(my_organization_id).suggested_reviewers_bot

Notes

  • New internal bot users for the non-default organization will be named differently. For example, instead of admin_bot , it may have the username admin_bot-acme-corp . It will have an Organizations::UserAlias associated to allow mentioning and referencing via the shorter, existing bot name admin_bot (on issues within the relevant Organization).
  • Changing queries may need review from database . In general, the calls to Users::Internal use an indexed query, so lookup should be fast. Creating a new user may be slow, though we have tried to ensure username conflicts do not arise
  • If referencing bot users in cron jobs or background migrations, it may help to memoize the lookup to prevent excess N+1 queries. Keep in mind there may be up to 100k+ Organizations per cell, so memory usage may become a constraint
  • For an example MR of this type of migration, see the admin_bot migration MR - !193109 (merged)
Edited by François Rosé