Split In-App vs CLI storage notification logic
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:
- We remove the
notification
model layer of the notification architecture. We also removedcli notification
model-
In-App notifications
: now have all their logic inside the ViewComponent (limit_alert_component.rb
) -
CLI notifications
are now using:-
RepositorySizeErrorMessage
class for repository enforcement alerts -
NamespaceStorageSizeErrorMessage
class for namespace enforcement alerts
-
- There was only 1 place for CLI notifications still using the
notification
model, and we've changed it now inpost_receive_service.rb
to use the classes above
-
- With the
In-App notifications
logic all concentrated inlimit_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- 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 thehaml
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 - When I was moving the code from
notification.rb
tolimit_alert_component.rb
I changed some names so it's more readable/friendly
- The code in
- 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
git push
message)
CLI Alerts (i.e. Note:
- The line breaks (and word breaks) are due to the size of my terminal window. We don't have control over that.
- The red lines are there for visual aid. They don't appear on users' terminal. This message is text only
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
Note: some parts of this are cached. Here are the instructions to clear cache:
- Invalidate
redis
cache:- On your terminal, go to your gitlab project folder
- Execute:
rails cache:clear
- This might take over a minute
-
Invalidate
strong_memoize
:- On your terminal, go to your gitlab project folder
- Open rails console:
rails c
- 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
- Initial setup:
- Disable Feature Flags
- 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😅 ) - Create a
Group
and aProject
to work with. Take note of theirIDs
Now for each type of alert:
- Project over free tier limit and no purchased storage
- Make sure you don't have purchased storage:
Group.find(<group id>).update(additional_purchased_storage_size: 0)
- Add enough storage to your project so that it goes over the free tier limit:
- If you refer to the docs, it's the 4th row of the 1st column.
- Change
rough_percentage_used
in the script to110
for example
- Make sure you don't have purchased storage:
- Project over free tier limit; with purchased storage; under purchased limit
- Use the same project as above, add purchased storage
- If you refer to the docs, it's the 5th row of the 1st column.
- Copy and paste the script as is (update only the
Group ID
part)
- Project over free tier limit; with purchased storage; over purchased limit
- Use the same project as above, change purchased storage
- If you refer to the docs, it's the 5th row of the 1st column.
- Change
rough_percentage_used
in the script to110
for example
2. Namespace limits
- Initial setup:
- Enable Feature Flags and Application Setting
- 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😅 ) - Create a
Group
and aProject
to work with. Take note of theirIDs
Now for each type of alert:
- Namespace storage; with or without purchased storage; under total limit
- Add some namespace storage
- If you refer to the docs, it's the 4th row of the 2nd column.
- Copy and paste the script as is (update only the
Group ID
part)
- Namespace storage; with or without purchased storage; over total limit
- Use the same namespace as above, change your namespace storage
- If you refer to the docs, it's the 4th row of the 2nd column.
- 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
git push
message)
CLI Alerts (i.e. You'll need to perform a git push
on the project you created:
- Go to your project page:
https://gdk.test:3443/your-group/your-project
- Use the
Clone
button to copy your project's remote url, e.g.https://gdk.test:3443/your-group/your-project.git
- On your terminal, clone your repository:
git clone https://gdk.test:3443/your-group/your-project
- Enter your project's folder:
cd your-project
- Create a dummy file:
touch new-file
- Stage your changes:
git add .
- Create a new commit:
git commit
- Try to push the new changes to your remote:
git push
- You should see the messages in the terminal as they are in the screenshots.
- 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.
-
I have evaluated the MR acceptance checklist for this MR.