Skip to content
代码片段 群组 项目
  • Dylan Griffith's avatar
    016c3969
    Remove migration downtime check since we do not allow downtime · 016c3969
    Dylan Griffith 创作于
    For 4 years we've had logic in our database migrations that required you
    to set a constant `DOWNTIME = true` if you required downtime and seek
    approval from the VP of Engineering. We have never once used this
    process as we've always found a way around the problem using a different
    approach.
    
    As such we decided in
    https://gitlab.com/gitlab-org/gitlab/-/issues/326495 that we should just
    remove this `DOWNTIME` constant and the extra checks here to reduce
    noise in our database code review and give less processes for people to
    learn.
    
    This MR removes a lot of things and here is a high level summary:
    
    1. Remove DowntimeCheck class and the rake task that invoked and the CI
    job that invoked that rake task and any related tests, helper classes
    2. Update documentation to make it clearer that downtime is not allowed
    and therefore remove the approval process
    3. Update a page called `what_requires_downtime` to be called
    `avoiding_downtime_in_migrations` since it was already a set of patterns
    to avoid downtime and now it's worded more strongly to imply that we can
    always get away without downtime
    4. Various other docs pages that had examples of migrations that used
    the `DOWNTIME` constant
    5. Various rubocop specs that had migrations in them which used the
    `DOWNTIME` constant
    
    The one thing I did not do is go back and remove `DOWNTIME = false` from
    all the existing migrations. In general we should not be updating
    migrations once they've run and this would have made this MR change many
    thousands of files so it's not worth it.
    016c3969
    历史
    Remove migration downtime check since we do not allow downtime
    Dylan Griffith 创作于
    For 4 years we've had logic in our database migrations that required you
    to set a constant `DOWNTIME = true` if you required downtime and seek
    approval from the VP of Engineering. We have never once used this
    process as we've always found a way around the problem using a different
    approach.
    
    As such we decided in
    https://gitlab.com/gitlab-org/gitlab/-/issues/326495 that we should just
    remove this `DOWNTIME` constant and the extra checks here to reduce
    noise in our database code review and give less processes for people to
    learn.
    
    This MR removes a lot of things and here is a high level summary:
    
    1. Remove DowntimeCheck class and the rake task that invoked and the CI
    job that invoked that rake task and any related tests, helper classes
    2. Update documentation to make it clearer that downtime is not allowed
    and therefore remove the approval process
    3. Update a page called `what_requires_downtime` to be called
    `avoiding_downtime_in_migrations` since it was already a set of patterns
    to avoid downtime and now it's worded more strongly to imply that we can
    always get away without downtime
    4. Various other docs pages that had examples of migrations that used
    the `DOWNTIME` constant
    5. Various rubocop specs that had migrations in them which used the
    `DOWNTIME` constant
    
    The one thing I did not do is go back and remove `DOWNTIME = false` from
    all the existing migrations. In general we should not be updating
    migrations once they've run and this would have made this MR change many
    thousands of files so it's not worth it.
代码所有者
将用户和群组指定为特定文件更改的核准人。 了解更多。
stage: Enablement
group: Distribution
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

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 limits that are set for the different GitLab tiers. You also need to coordinate with others to document and communicate those limits.

There is a guide about introducing application limits.

Development

Insert database plan limits

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:

    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.

  2. (Optionally) Create the database migration that fine-tunes each level with a desired limit using create_or_update_plan_limit migration helper, such as:

    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

    Some plans exist only on GitLab.com. This is a no-op for plans that do not exist.

Plan limits validation

Get current limit

Access to the current limit can be done through the project or the namespace, such as:

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.

Ensures that the count of the records does not exceed the defined limit, such as:

project.actual_limits.exceeded?(:project_hooks, ProjectHook.where(project: project))

Ensures that the number does not exceed the defined limit, such as:

project.actual_limits.exceeded?(:project_hooks, 10)

Limitable concern

The Limitable concern 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.

You must specify the limit scope of the object being validated and the limit name if it's different from the pluralized model name.

class ProjectHook
  include Limitable

  self.limit_name = 'project_hooks' # Optional as ProjectHook corresponds with project_hooks
  self.limit_scope = :project
end

To test the model, you can include the shared examples.

it_behaves_like 'includes Limitable concern' do
  subject { build(:project_hook, project: create(:project)) }
end

Testing instance-wide limits

Instance-wide features always use default Plan, as instance-wide features do not have license assigned.

class InstanceVariable
  include Limitable

  self.limit_name = 'instance_variables' # Optional as InstanceVariable corresponds with instance_variables
  self.limit_scope = Limitable::GLOBAL_SCOPE
end

Subscription Plans

Self-managed:

  • default: Everyone.

GitLab.com:

  • 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.

The test environment doesn't have any plans.