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 usernameadmin_bot-acme-corp
. It will have anOrganizations::UserAlias
associated to allow mentioning and referencing via the shorter, existing bot nameadmin_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)