Skip to content

Split In-App vs CLI storage notification logic

Sheldon Led requested to merge led/371674-split-namespace-repository-logic into master

What does this MR do and why?

This MR is a result of an investigation that started when estimating this issue (discussion: https://gitlab.com/gitlab-org/gitlab/-/issues/371674#note_1214125378) where we've identified that changing the copy on notification alerts was quite complicated given the way the code was written.

During the investigation I've noticed that CLI notifications weren't using the notification model in most scenarios, so it is easier to consolidate the CLI notifications in another code flow, and transfer the logic in the notification model to limit_alert_component.rb.

So this is what this MR is doing:

  1. We remove the notification model layer of the notification architecture. We also removed cli notification model
    1. In-App notifications: now have all their logic inside the ViewComponent (limit_alert_component.rb)
    2. CLI notifications are now using:
      1. RepositorySizeErrorMessage class for repository enforcement alerts
      2. NamespaceStorageSizeErrorMessage class for namespace enforcement alerts
    3. There was only 1 place for CLI notifications still using the notification model, and we've changed it now in post_receive_service.rb to use the classes above
  2. With the In-App notifications logic all concentrated in limit_alert_component.rb ViewComponent we have more flexibility to introduce rich text using, for example, html_safe to parse html content, as well as having the paragraphs in an array so we can introduce multiple paragraphs like it's currently being asked in https://gitlab.com/gitlab-org/gitlab/-/issues/371674
    1. The code in limit_alert_component.rb is still combining repository & namespace messages, so I tried to separate the methods by their usage: first methods used in the haml file, then the auxiliary methods at the bottom. I judged that at this moment breaking the component in 2 would cause more noise to this MR, but it's something we might want to do in the future
    2. When I was moving the code from notification.rb to limit_alert_component.rb I changed some names so it's more readable/friendly
  3. I've added unit tests for limit_alert_component.rb with the 5 scenarios represented in the screenshots below

Screenshots or screen recordings

In-app Alerts

Repository Limit Alerts Namespace Limit Alerts
Project over free tier limit and no purchased storage repo_storage_over_limit_no_purchased_storage ---
Project over free tier limit; with purchased storage; under purchased limit repo_storage_over_limit_with_purchased_storage_under_limit Namespace storage; with or without purchased storage; under total limit namespcace_storage_under_limit
Project over free tier limit; with purchased storage; over purchased limit repo_storage_over_limit_with_purchased_storage_over_limit Namespace storage; with or without purchased storage; over total limit namespcace_storage_over_limit

CLI Alerts (i.e. git push message)

Note:

  1. The line breaks (and word breaks) are due to the size of my terminal window. We don't have control over that.
  2. The red lines are there for visual aid. They don't appear on users' terminal. This message is text only
Repository Limit Alerts Namespace Limit Alerts
Project over free tier limit and no purchased storage cli_repo_storage_over_limit_no_purchased_storage ---
Project over free tier limit; with purchased storage; under purchased limit cli_repo_storage_over_limit_with_purchased_storage_under_limit Namespace storage; with or without purchased storage; under total limit cli_namespcace_storage_under_limit
Project over free tier limit; with purchased storage; over purchased limit cli_repo_storage_over_limit_with_purchased_storage_over_limit Namespace storage; with or without purchased storage; over total limit cli_namespcace_storage_over_limit

How to set up and validate locally

The instructions below are based on this section of the storage docs, you'll find a table that aims to help to differentiate between Namespace vs Repository limits. Please use that table to setup things on your local environment.

I've recorded a YouTube video where I go over each step of the validation

Watch the video

Note: some parts of this are cached. Here are the instructions to clear cache:

  1. Invalidate redis cache:
    1. On your terminal, go to your gitlab project folder
    2. Execute: rails cache:clear
    3. This might take over a minute
  2. Invalidate strong_memoize:
    1. On your terminal, go to your gitlab project folder
    2. Open rails console: rails c
    3. Create a new instance of the class containing the memoization and clear the necessary key: Namespaces::Storage::RootExcessSize.new.clear_memoization(:limit)

Important: when testing CLI notifications, some git push commands will go through, and this will recalculate your project storage. Please be aware of that as it will impact your setup.

1. Repository limits

  1. Initial setup:
    1. Disable Feature Flags
    2. Set your desired repository_size_limit amount (I suggest a big number of megabytes (so we can work with integers) and something easy to work with percentages 😅 )
    3. Create a Group and a Project to work with. Take note of their IDs

Now for each type of alert:

  1. Project over free tier limit and no purchased storage
    1. Make sure you don't have purchased storage: Group.find(<group id>).update(additional_purchased_storage_size: 0)
    2. Add enough storage to your project so that it goes over the free tier limit:
      1. If you refer to the docs, it's the 4th row of the 1st column.
      2. Change rough_percentage_used in the script to 110 for example
  2. Project over free tier limit; with purchased storage; under purchased limit
    1. Use the same project as above, add purchased storage
    2. If you refer to the docs, it's the 5th row of the 1st column.
    3. Copy and paste the script as is (update only the Group ID part)
  3. Project over free tier limit; with purchased storage; over purchased limit
    1. Use the same project as above, change purchased storage
    2. If you refer to the docs, it's the 5th row of the 1st column.
    3. Change rough_percentage_used in the script to 110 for example

2. Namespace limits

  1. Initial setup:
    1. Enable Feature Flags and Application Setting
    2. Add storage_size_limit limits to the free/default plan (I suggest a big number of megabytes (so we can work with integers) and something easy to work with percentages 😅 )
    3. Create a Group and a Project to work with. Take note of their IDs

Now for each type of alert:

  1. Namespace storage; with or without purchased storage; under total limit
    1. Add some namespace storage
    2. If you refer to the docs, it's the 4th row of the 2nd column.
    3. Copy and paste the script as is (update only the Group ID part)
  2. Namespace storage; with or without purchased storage; over total limit
    1. Use the same namespace as above, change your namespace storage
    2. If you refer to the docs, it's the 4th row of the 2nd column.
    3. Change rough_percentage_used to 110

3. Ok I setup the things above, how can I see the alerts like in the screenshots?

In-app Alerts

The alerts will show on your group page: https://gdk.test:3443/groups/your-group

CLI Alerts (i.e. git push message)

You'll need to perform a git push on the project you created:

  1. Go to your project page: https://gdk.test:3443/your-group/your-project
  2. Use the Clone button to copy your project's remote url, e.g. https://gdk.test:3443/your-group/your-project.git
  3. On your terminal, clone your repository: git clone https://gdk.test:3443/your-group/your-project
  4. Enter your project's folder: cd your-project
  5. Create a dummy file: touch new-file
  6. Stage your changes: git add .
  7. Create a new commit: git commit
  8. Try to push the new changes to your remote: git push
  9. You should see the messages in the terminal as they are in the screenshots.
  10. Please Note: for the warnings, your commit will go through. This will recalculate your project storage. Please be aware of that as it will impact your setup.

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