debian-mirror-gitlab/doc/development/application_limits.md

151 lines
4.6 KiB
Markdown
Raw Normal View History

2021-01-29 00:20:46 +05:30
---
2021-03-11 19:13:27 +05:30
stage: Enablement
group: Distribution
2021-02-22 17:27:13 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2021-01-29 00:20:46 +05:30
---
2020-03-13 15:44:24 +05:30
# Application limits development
This document provides a development guide for contributors to add application
limits to GitLab.
## Documentation
First of all, you have to gather information and decide which are the different
2021-02-22 17:27:13 +05:30
limits that are set for the different GitLab tiers. You also need to
2020-03-13 15:44:24 +05:30
coordinate with others to [document](../administration/instance_limits.md)
and communicate those limits.
There is a guide about [introducing application
2020-07-28 23:09:34 +05:30
limits](https://about.gitlab.com/handbook/product/product-processes/#introducing-application-limits).
2020-03-13 15:44:24 +05:30
## Development
### Insert database plan limits
2020-11-24 15:15:51 +05:30
In the `plan_limits` table, create a new column and insert the limit values.
It's recommended to create two separate migration script files.
1. Add a new column to the `plan_limits` table with non-null default value that
represents desired limit, such as:
```ruby
add_column(:plan_limits, :project_hooks, :integer, default: 100, null: false)
```
Plan limits entries set to `0` mean that limits are not enabled. You should
use this setting only in special and documented circumstances.
1. (Optionally) Create the database migration that fine-tunes each level with a
desired limit using `create_or_update_plan_limit` migration helper, such as:
```ruby
class InsertProjectHooksPlanLimits < ActiveRecord::Migration[5.2]
include Gitlab::Database::MigrationHelpers
def up
create_or_update_plan_limit('project_hooks', 'default', 0)
create_or_update_plan_limit('project_hooks', 'free', 10)
create_or_update_plan_limit('project_hooks', 'bronze', 20)
create_or_update_plan_limit('project_hooks', 'silver', 30)
create_or_update_plan_limit('project_hooks', 'gold', 100)
end
def down
create_or_update_plan_limit('project_hooks', 'default', 0)
create_or_update_plan_limit('project_hooks', 'free', 0)
create_or_update_plan_limit('project_hooks', 'bronze', 0)
create_or_update_plan_limit('project_hooks', 'silver', 0)
create_or_update_plan_limit('project_hooks', 'gold', 0)
end
end
```
2021-02-22 17:27:13 +05:30
Some plans exist only on GitLab.com. This is a no-op for plans
2020-11-24 15:15:51 +05:30
that do not exist.
2020-03-13 15:44:24 +05:30
### Plan limits validation
#### Get current limit
Access to the current limit can be done through the project or the namespace,
2020-06-23 00:09:42 +05:30
such as:
2020-03-13 15:44:24 +05:30
```ruby
project.actual_limits.project_hooks
```
#### Check current limit
There is one method `PlanLimits#exceeded?` to check if the current limit is
being exceeded. You can use either an `ActiveRecord` object or an `Integer`.
2020-06-23 00:09:42 +05:30
Ensures that the count of the records does not exceed the defined limit, such as:
2020-03-13 15:44:24 +05:30
```ruby
project.actual_limits.exceeded?(:project_hooks, ProjectHook.where(project: project))
```
2020-06-23 00:09:42 +05:30
Ensures that the number does not exceed the defined limit, such as:
2020-03-13 15:44:24 +05:30
```ruby
project.actual_limits.exceeded?(:project_hooks, 10)
```
#### `Limitable` concern
2020-05-24 23:13:21 +05:30
The [`Limitable` concern](https://gitlab.com/gitlab-org/gitlab/blob/master/app/models/concerns/limitable.rb)
2020-03-13 15:44:24 +05:30
can be used to validate that a model does not exceed the limits. It ensures
that the count of the records for the current model does not exceed the defined
limit.
2020-07-28 23:09:34 +05:30
You must specify the limit scope of the object being validated
2020-04-08 14:13:33 +05:30
and the limit name if it's different from the pluralized model name.
2020-03-13 15:44:24 +05:30
```ruby
class ProjectHook
include Limitable
2020-04-08 14:13:33 +05:30
self.limit_name = 'project_hooks' # Optional as ProjectHook corresponds with project_hooks
self.limit_scope = :project
2020-03-13 15:44:24 +05:30
end
```
2020-04-08 14:13:33 +05:30
To test the model, you can include the shared examples.
```ruby
it_behaves_like 'includes Limitable concern' do
subject { build(:project_hook, project: create(:project)) }
end
```
2020-06-23 00:09:42 +05:30
### Testing instance-wide limits
Instance-wide features always use `default` Plan, as instance-wide features
do not have license assigned.
```ruby
class InstanceVariable
include Limitable
self.limit_name = 'instance_variables' # Optional as InstanceVariable corresponds with instance_variables
self.limit_scope = Limitable::GLOBAL_SCOPE
end
```
2020-04-08 14:13:33 +05:30
### Subscription Plans
Self-managed:
2021-04-17 20:07:23 +05:30
- `default`: Everyone.
2020-04-08 14:13:33 +05:30
GitLab.com:
2021-04-17 20:07:23 +05:30
- `default`: Any system-wide feature.
- `free`: Namespaces and projects with a Free subscription.
- `bronze`: Namespaces and projects with a Bronze subscription. This tier is no longer available for purchase.
- `silver`: Namespaces and projects with a Premium subscription.
- `gold`: Namespaces and projects with an Ultimate subscription.
2020-04-08 14:13:33 +05:30
2021-01-29 00:20:46 +05:30
The `test` environment doesn't have any plans.