Skip to content

Skip license capacity check for security policy bot user

What does this MR do and why?

This MR fixes a problem identified in GitLab Security Policy Bot can be blocked as a ... (#439129 - closed) where we required additional approval for creation of Security Policy Bot user in certain cases. This MR resolves that issue.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

How to set up and validate locally

From #439129 (closed):

  1. Create a GDK instance.
  2. Setup the GDK instance to simulate GitLab.com with: export GITLAB_SIMULATE_SAAS=1 in the env.runit file, and follow the steps to allow use of licensed EE features to be available to groups.
  3. Once the instance is operational, enable FF with: Feature.enable(:saas_user_caps) via GDK rails console. (This is enabled on GitLab.com).
  4. Create a new top-level group, and set a user-cap of 1. This will limit the max users to just the existing user that created the group.
  5. Within the Admin Area, set the new group to 'Ultimate'.
  6. Within the top-level group, create a new scan execution policy that attempts to run on a schedule, such as for Dependency Scanning every 15 minutes.
  7. Create a project beneath the top-level group.
  8. Go to the top-level group's Usage Quotas > Pending Members page (for example: http://localhost:3000/groups/<top-level-group>/-/usage_quotas/pending_members) and confirm that there are no pending users in the members list.

Related to #439129 (closed)

Merge request reports

Loading