Skip to content

Add remaining details to storage notification banner

Sheldon Led requested to merge led/349042-remaining-details into master

What does this MR do and why?

Relates to https://gitlab.com/gitlab-org/gitlab/-/issues/349042

This adds the remaining requirements for the storage notification banner:

  • Add the ability to display this banner for the user namespaces
  • Show the banner for project maintainers
  • Only show the purchase link if the user is the owner of the root namespace

For this MR the history of change isn't that necessary, but here it is, in case you want to have a look at the related changes:

MR description
!89455 (merged) Remove CE code
!88912 (merged) Refactor backend logic to show notification
!91878 (merged) Refactor banner into ViewComponent and add user_callouts for each threshold
!92642 (merged) 👈 (You're here) Add remaining details to storage notification banner

Screenshots or screen recordings

Here are the variations of the banner:

  1. Project locked due to project-level (repository) storage limit 92642-banner1
  2. Repository storage limit with locked projects 92642-banner2
  3. namespace usage notification based on additional purchase + project-level (repository) storage limit 92642-banner3
  4. Namespace level storage notification, based on the namespace plan limit 92642-banner4
  5. Seeing the banner as maintainer: 92642-seeing-the-banner-as-maintainer

How to set up and validate locally

  1. Make sure to enable these:
    1. ::Gitlab::CurrentSettings.update(enforce_namespace_storage_limit: true)
    2. ::Gitlab::CurrentSettings.update(automatic_purchased_storage_allocation: true)
    3. ::Gitlab::CurrentSettings.update(check_namespace_plan: true)
    4. Make sure you're simulating SaaS

Repository level storage notifications

  1. This is the legacy lock, so we need to disable the FF: Feature.disable(:namespace_storage_limit)

First banner - project locked due to project-level (repository) storage limit

  1. To make sure we lock projects over the storage limit, let's add a 10 Bytes limit: ::Gitlab::CurrentSettings.update!(repository_size_limit: 10)
  2. Now let's add some storage statistics to the project so it goes over the limit and gets locked:
    p = Project.find(<your project id here>)
    
    p.statistics.update(
      repository_size: 3900000000,
      lfs_objects_size: 4800000000,
      build_artifacts_size: 400000000,
      wiki_size: 300000000,
      packages_size: 3800000000
    )
  3. Now if you navigate to the group's home page (or the group's project page) you should see the banner.

92642-banner1

  1. To toggle the message let's add some additional purchased storage
    n = Group.find(<your group id here>)
    n.update(additional_purchased_storage_size: 15)
  2. Now you should see a message like this:

92642-banner2

Second banner - namespace usage notification based on additional purchase + project-level (repository) storage limit

To see this variation of the banner we need to have a bigger additional_purchased_storage_size. In order to do that, on the same group as above:

  1. Check what you have as total_repository_size_excess (on rails console: Group.find(<your group id here>).total_repository_size_excess),
  2. Have X.megabites bigger than total_repository_size_excess.
    • For example, in my case total_repository_size_excess is 8 699 999 990, so I'll use 8700 because 8700.megabytes is 9 122 611 200
    • You can also toggle this difference so we can test different usage thresholds (50%, 75%, 95%, and 100%) but having 100% could trigger the other banner depending on the rounding.
  3. Then update the namespace accordingly Group.find(232).update(additional_purchased_storage_size: 8700)
  4. You should see a banner with the following message: 92642-banner3

Namespace level storage notifications

These banners are based on the plan limit - as part of this bigger effort https://gitlab.com/groups/gitlab-org/-/epics/6587.

  1. First step is to enable the FF that toggles the type of enforcement from repository to namespace storage: Feature.enable(:namespace_storage_limit)
    • This will make the repository-level storage banners (mentioned above) to stop showing
  2. Next we need to enable other feature flags that control other parts of this feature
    1. Feature.enable(:namespace_storage_limit_bypass_date_check)
    2. Feature.enable(:enforce_storage_limit_for_paid)
    3. Feature.enable(:enforce_storage_limit_for_free)
  3. Let's add a limit to the free plan (10 here means 10 megabytes):
    1. Plan.default.actual_limits.update!(storage_size_limit: 10)
    2. Plan.free.actual_limits.update!(storage_size_limit: 10)
  4. If you're using the same group for all examples, let's remove the additional purchased storage:
    1. n = Group.find(<your group id here>)
    2. n.update(additional_purchased_storage_size: 0)
  5. Now let's add some namespace storage statistics. If the limit is 10.megabytes (10485760) here are some examples:
    1. info banner (50%): 5242880
    2. warning banner (75%): 7864320
    3. alert banner (95%): 9961472
    4. error banner (100%): 10485760
    5. error banner over limit (100+%): 11000000
    6. You can use these numbers in one storage statistic, or distributed amongst them. Here's an example with 75% storage used:
    n = Group.find(<your group id here>)
    n.root_storage_statistics&.destroy!
    s = Namespace::RootStorageStatistics.new(
      namespace: n,
      build_artifacts_size: 0,
      wiki_size: 0,
      repository_size: 0,
      packages_size: 0,
      lfs_objects_size: 7864320
    )
    s.storage_size = s.repository_size + s.lfs_objects_size + s.wiki_size + s.build_artifacts_size + s.packages_size
    s.save!
    1. Beware that there are chached information all around, so you might need to restart gdk
    2. You should see a banner like this: 92642-banner4

With that we can test these banners before and after the refactoring, and assert they're working fine.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Sheldon Led

Merge request reports