root
/
gitlab-ce
mirror of https://gitlab.com/free-releases/gitlab-ce.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2023-07-14 09:09:23 +00:00
parent aa6aa484ea
commit 7a7f602c26
65 changed files with 922 additions and 616 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
GITALY_SERVER_VERSION
View File

@ -1 +1 @@
134d4077537e30d72a7b61805c99660eb66bef22
f2c232b9898c255cff523240d7f53b77ae698e74

29
app/components/pajamas/empty_state_component.html.haml Normal file
View File

@ -0,0 +1,29 @@
- empty_state_class = @compact ? 'gl-flex-direction-row gl-align-items-center' : 'gl-text-center gl-flex-direction-column'
%section.gl-display-flex.empty-state{ **@empty_state_options, class: empty_state_class }
- if @svg_path.present?
- image_class = @compact ? 'gl-display-none gl-sm-display-block gl-px-4' : 'gl-max-w-full'
%div{ class: image_class }
= image_tag @svg_path, alt: "", class: 'gl-dark-invert-keep-hue'
- content_wrapper_class = @compact ? 'gl-flex-grow-1 gl-flex-basis-0 gl-px-4' : 'gl-max-w-full gl-m-auto pl-p-5'
%div{ class: content_wrapper_class }
- title_class = @compact ? 'gl-mt-0' : 'gl-my-3'
%h1.gl-font-size-h-display.gl-line-height-36{ class: title_class }
= @title
- if description?
%p.gl-mt-3{ 'data-testid': 'empty-state-description' }
= description
- if @primary_button_text.present? || @secondary_button_text.present?
- button_wrapper_class = @compact.present? ? '' : 'gl-justify-content-center'
.gl-display-flex.gl-flex-wrap{ class: button_wrapper_class }
- if @primary_button_text.present?
= render Pajamas::ButtonComponent.new(variant: :confirm, href: @primary_button_link, button_options: { class: 'gl-ml-0!' }) do
= @primary_button_text
- if @secondary_button_text.present?
= render Pajamas::ButtonComponent.new(variant: :default, href: @secondary_button_link, button_options: { class: ('gl-ml-0!' unless @primary_button_text.present?) }) do
= @secondary_button_text

35
app/components/pajamas/empty_state_component.rb Normal file
View File

@ -0,0 +1,35 @@
# frozen_string_literal: true
module Pajamas
class EmptyStateComponent < Pajamas::Component
# @param [Boolean] compact
# @param [String] title
# @param [String] svg_path
# @param [String] primary_button_text
# @param [String] primary_button_link
# @param [String] secondary_button_text
# @param [String] secondary_button_link
# @param [Hash] empty_state_options
def initialize(
compact: false,
title: nil,
svg_path: nil,
primary_button_text: nil,
primary_button_link: nil,
secondary_button_text: nil,
secondary_button_link: nil,
empty_state_options: {}
)
@compact = compact
@title = title
@svg_path = svg_path.to_s
@primary_button_text = primary_button_text
@primary_button_link = primary_button_link
@secondary_button_text = secondary_button_text
@secondary_button_link = secondary_button_link
@empty_state_options = empty_state_options
end
renders_one :description
end
end

3
app/helpers/auth_helper.rb
View File

@ -53,7 +53,8 @@ module AuthHelper
saml: 'saml_login_button',
openid_connect: 'oidc_login_button',
github: 'github_login_button',
gitlab: 'gitlab_oauth_login_button'
gitlab: 'gitlab_oauth_login_button',
facebook: 'facebook_login_button'
}[provider.to_sym]
end

2
app/models/alert_management/http_integration.rb
View File

@ -21,7 +21,7 @@ module AlertManagement
validates :name, presence: true, length: { maximum: 255 }
validates :type_identifier, presence: true
validates :endpoint_identifier, presence: true, length: { maximum: 255 }, format: { with: /\A[A-Za-z0-9-]+\z/ }
validates :endpoint_identifier, uniqueness: { scope: [:project_id, :active] }, if: :active?
validates :endpoint_identifier, uniqueness: { scope: [:project_id] }
validates :payload_attribute_mapping, json_schema: { filename: 'http_integration_payload_attribute_mapping' }
before_validation :prevent_token_assignment

6
app/models/user.rb
View File

@ -1830,8 +1830,12 @@ class User < ApplicationRecord
Project.where(id: events).not_aimed_for_deletion
end
# Returns true if the user can be removed, false otherwise.
# A user can be removed if they do not own any groups where they are the sole owner
# Method `none?` is used to ensure faster retrieval, See https://gitlab.com/gitlab-org/gitlab/-/issues/417105
def can_be_removed?
!solo_owned_groups.present?
solo_owned_groups.none?
end
def can_remove_self?

2
app/views/admin/application_settings/_usage.html.haml
View File

@ -37,7 +37,7 @@
.form-text.gl-text-gray-500.gl-pl-6
%p.gl-mb-3= s_('AdminSettings|Registration Features include:')
- email_from_gitlab_path = help_page_path('user/admin_area/email_from_gitlab')
- repo_size_limit_path = help_page_path('user/admin_area/settings/account_and_limit_settings', anchor: 'repository-size-limit')
- repo_size_limit_path = help_page_path('administration/settings/account_and_limit_settings', anchor: 'repository-size-limit')
- restrict_ip_path = help_page_path('user/group/access_and_permissions', anchor: 'restrict-group-access-by-ip-address')
- email_from_gitlab_link = link_start % { url: email_from_gitlab_path }
- repo_size_limit_link = link_start % { url: repo_size_limit_path }

40
db/post_migrate/20230707211358_deduplicate_inactive_alert_integrations.rb Normal file
View File

@ -0,0 +1,40 @@
# frozen_string_literal: true
class DeduplicateInactiveAlertIntegrations < Gitlab::Database::Migration[2.1]
restrict_gitlab_migration gitlab_schema: :gitlab_main
class HttpIntegration < MigrationRecord
self.table_name = 'alert_management_http_integrations'
end
# Existing unique index ensures that all active integrations are already unique.
# Any non-unique records must be inactive by definition, but dups are unlikely.
# At time of writing, gitlab.com has 0 records in this state.
# Of the ~1600 integrations, only ~100 are even inactive.
def up
duplicated_identifiers.each do |(project_id, endpoint_identifier)|
find_inactive_integrations(project_id, endpoint_identifier).delete_all
end
end
def down
# no-op -> unable to identify duplicates retroactively
end
private
def duplicated_identifiers
HttpIntegration
.group(:project_id, :endpoint_identifier)
.having('count(id) > 1')
.pluck(:project_id, :endpoint_identifier)
end
def find_inactive_integrations(project_id, endpoint_identifier)
HttpIntegration.where(
project_id: project_id,
endpoint_identifier: endpoint_identifier,
active: false
)
end
end

33
db/post_migrate/20230707211359_change_alert_integrations_unique_index.rb Normal file
View File

@ -0,0 +1,33 @@
# frozen_string_literal: true
# Swaps the unique index for AlertManagement::HttpIntegration to include
# inactive integrations, making performance optimizations easier.
#
# At time of writing, gitlab.com has 0 records which would be invalidated
# by the new index. Of the ~1600 integrations, only ~100 are inactive, so the
# size of the index will not significantly change.
class ChangeAlertIntegrationsUniqueIndex < Gitlab::Database::Migration[2.1]
disable_ddl_transaction!
UNIQUE_INDEX_NAME = 'index_http_integrations_on_project_and_endpoint'
OLD_INDEX_NAME = 'index_http_integrations_on_active_and_project_and_endpoint'
def up
add_concurrent_index :alert_management_http_integrations,
[:project_id, :endpoint_identifier],
name: UNIQUE_INDEX_NAME,
unique: true
remove_concurrent_index_by_name :alert_management_http_integrations, OLD_INDEX_NAME
end
def down
add_concurrent_index :alert_management_http_integrations,
[:active, :project_id, :endpoint_identifier],
unique: true,
name: OLD_INDEX_NAME,
where: 'active'
remove_concurrent_index_by_name :alert_management_http_integrations, UNIQUE_INDEX_NAME
end
end

1
db/schema_migrations/20230707211358 Normal file
View File

@ -0,0 +1 @@
1f2ae1ac4c26b8fe257c158e9c1b9a99a590176e8566d7b9f22c4265177c861a

1
db/schema_migrations/20230707211359 Normal file
View File

@ -0,0 +1 @@
7b319745b746418deedc6130cf6ed2860e0c4a01af9b15548dfacac314cdabe2

2
db/structure.sql
View File

@ -31396,7 +31396,7 @@ CREATE INDEX index_groups_on_path_and_id ON namespaces USING btree (path, id) WH
CREATE INDEX index_historical_data_on_recorded_at ON historical_data USING btree (recorded_at);
CREATE UNIQUE INDEX index_http_integrations_on_active_and_project_and_endpoint ON alert_management_http_integrations USING btree (active, project_id, endpoint_identifier) WHERE active;
CREATE UNIQUE INDEX index_http_integrations_on_project_and_endpoint ON alert_management_http_integrations USING btree (project_id, endpoint_identifier);
CREATE INDEX index_identities_on_saml_provider_id ON identities USING btree (saml_provider_id) WHERE (saml_provider_id IS NOT NULL);

2
doc/administration/auth/ldap/ldap_synchronization.md
View File

@ -40,7 +40,7 @@ For more information, see [Bitmask Searches in LDAP](https://ctovswild.com/2009/
The process also updates the following user information:
- Name. Because of a [sync issue](https://gitlab.com/gitlab-org/gitlab/-/issues/342598), `name` is not synchronized if
[**Prevent users from changing their profile name**](../../../user/admin_area/settings/account_and_limit_settings.md#disable-user-profile-name-changes) is enabled or `sync_name` is set to `false`.
[**Prevent users from changing their profile name**](../../../administration/settings/account_and_limit_settings.md#disable-user-profile-name-changes) is enabled or `sync_name` is set to `false`.
- Email address.
- SSH public keys if `sync_ssh_keys` is set.
- Kerberos identity if Kerberos is enabled.

2
doc/administration/instance_limits.md
View File

@ -928,7 +928,7 @@ See the limits in the [Add a design to an issue](../user/project/issues/design_m
### Max push size
The maximum allowed [push size](../user/admin_area/settings/account_and_limit_settings.md#max-push-size) is set to 5 GB.
The maximum allowed [push size](../administration/settings/account_and_limit_settings.md#max-push-size) is set to 5 GB.
### Webhooks and Project Services

399
doc/administration/settings/account_and_limit_settings.md Normal file
View File

@ -0,0 +1,399 @@
---
stage: Create
group: Source Code
info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments"
type: reference
---
# Account and limit settings **(FREE SELF)**
## Default projects limit
You can configure the default maximum number of projects new users can create in their
personal namespace. This limit affects only new user accounts created after you change
the setting. This setting is not retroactive for existing users, but you can separately edit
the [project limits for existing users](#projects-limit-for-a-user).
To configure the maximum number of projects in personal namespaces for new users:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**.
1. Increase or decrease that **Default projects limit** value.
If you set **Default projects limit** to 0, users are not allowed to create projects
in their users personal namespace. However, projects can still be created in a group.
### Projects limit for a user
You can edit a specific user, and change the maximum number of projects this user
can create in their personal namespace:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Overview** > **Users**.
1. From the list of users, select a user.
1. Select **Edit**.
1. Increase or decrease the **Projects limit** value.
## Max attachment size
> [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/20061) from 10 MB to 100 MB in GitLab 15.7.
The maximum file size for attachments in GitLab comments and replies is 100 MB.
To change the maximum attachment size:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**.
1. Increase or decrease by changing the value in **Maximum attachment size (MB)**.
If you choose a size larger than the configured value for the web server,
you may receive errors. Read the [troubleshooting section](#troubleshooting) for more
details.
For GitLab.com repository size limits, read [accounts and limit settings](../../user/gitlab_com/index.md#account-and-limit-settings).
## Max push size
You can change the maximum push size for your instance:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**.
1. Increase or decrease by changing the value in **Maximum push size (MB)**.
For GitLab.com push size limits, read [accounts and limit settings](../../user/gitlab_com/index.md#account-and-limit-settings).
NOTE:
When you [add files to a repository](../../user/project/repository/web_editor.md#create-a-file)
through the web UI, the maximum **attachment** size is the limiting factor,
because the [web server](../../development/architecture.md#components)
must receive the file before GitLab can generate the commit.
Use [Git LFS](../../topics/git/lfs/index.md) to add large files to a repository.
## Max export size
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86124) in GitLab 15.0.
To modify the maximum file size for exports in GitLab:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**, then expand **Account and limit**.
1. Increase or decrease by changing the value in **Maximum export size (MB)**.
## Max import size
> [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/251106) from 50 MB to unlimited in GitLab 13.8.
To modify the maximum file size for imports in GitLab:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**.
1. Increase or decrease by changing the value in **Maximum import size (MB)**.
This setting applies only to repositories
[imported from a GitLab export file](../../user/project/settings/import_export.md#import-a-project-and-its-data).
If you choose a size larger than the configured value for the web server,
you may receive errors. See the [troubleshooting section](#troubleshooting) for more
details.
For GitLab.com repository size limits, read [accounts and limit settings](../../user/gitlab_com/index.md#account-and-limit-settings).
## Personal access token prefix
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20968) in GitLab 13.7.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/342327) in GitLab 14.5, a default prefix.
You can specify a prefix for personal access tokens. You might use a prefix
to find tokens more quickly, or for use with automation tools.
The default prefix is `glpat-` but administrators can change it.
[Project access tokens](../../user/project/settings/project_access_tokens.md) and
[group access tokens](../../user/group/settings/group_access_tokens.md) also inherit this prefix.
### Set a prefix
To change the default global prefix:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand the **Account and limit** section.
1. Fill in the **Personal Access Token prefix** field.
1. Select **Save changes**.
You can also configure the prefix by using the
[settings API](../../api/settings.md).
## Repository size limit **(PREMIUM SELF)**
Repositories in your GitLab instance can grow quickly, especially if you are
using LFS. Their size can grow exponentially, rapidly consuming available storage.
To prevent this from happening, you can set a hard limit for your repositories' size.
This limit can be set globally, per group, or per project, with per project limits
taking the highest priority.
There are numerous use cases where you might set up a limit for repository size.
For instance, consider the following workflow:
1. Your team develops apps which require large files to be stored in
the application repository.
1. Although you have enabled [Git LFS](../../topics/git/lfs/index.md#git-large-file-storage-lfs)
to your project, your storage has grown significantly.
1. Before you exceed available storage, you set up a limit of 10 GB
per repository.
NOTE:
For GitLab.com repository size limits, read [accounts and limit settings](../../user/gitlab_com/index.md#account-and-limit-settings).
### How it works
Only a GitLab administrator can set those limits. Setting the limit to `0` means
there are no restrictions.
These settings can be found in:
- Each project's settings:
1. From the Project's homepage, navigate to **Settings > General**.
1. Fill in the **Repository size limit (MB)** field in the **Naming, topics, avatar** section.
1. Select **Save changes**.
- Each group's settings:
1. From the Group's homepage, navigate to **Settings > General**.
1. Fill in the **Repository size limit (MB)** field in the **Naming, visibility** section.
1. Select **Save changes**.
- GitLab global settings:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand the **Account and limit** section.
1. Fill in the **Size limit per repository (MB)** field.
1. Select **Save changes**.
The first push of a new project, including LFS objects, is checked for size.
If the sum of their sizes exceeds the maximum allowed repository size, the push
is rejected.
NOTE:
The repository size limit includes repository files and LFS, but does not include artifacts, uploads,
wiki, packages, or snippets. The repository size limit applies to both private and public projects.
For details on manually purging files, see [reducing the repository size using Git](../../user/project/repository/reducing_the_repo_size_using_git.md).
## Session duration
### Customize the default session duration
You can change how long users can remain signed in without activity.
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**. The set duration is in **Session duration (minutes)**.
If [Remember me](#turn-remember-me-on-or-off) is enabled, users' sessions can remain active for an indefinite period of time.
For details, see [cookies used for sign-in](../../user/profile/index.md#cookies-used-for-sign-in).
### Turn **Remember me** on or off
> Ability to turn the **Remember me** setting on and off [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/369133) in GitLab 16.0.
Users can select the **Remember me** checkbox on sign-in, and their session will remain active for an indefinite period of time when accessed from that specific browser. You can turn off this setting if you need sessions to expire for security or compliance purposes. Turning off this setting will ensure users' sessions expire after the number of minutes of inactivity set when you [customize your session duration](#customize-the-default-session-duration).
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**.
1. Select or clear the **Remember me** checkbox to turn this setting on or off.
### Customize session duration for Git Operations when 2FA is enabled **(PREMIUM SELF)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/296669) in GitLab 13.9.
> - It's deployed behind a feature flag, disabled by default.
FLAG:
On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `two_factor_for_cli`. On GitLab.com, this feature is not available. This feature is not ready for production use. This feature flag also affects [2FA for Git over SSH operations](../../security/two_factor_authentication.md#2fa-for-git-over-ssh-operations).
GitLab administrators can choose to customize the session duration (in minutes) for Git operations when 2FA is enabled. The default is 15 and this can be set to a value between 1 and 10080.
To set a limit on how long these sessions are valid:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand the **Account and limit** section.
1. Fill in the **Session duration for Git operations when 2FA is enabled (minutes)** field.
1. Select **Save changes**.
## Limit the lifetime of SSH keys **(ULTIMATE SELF)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1007) in GitLab 14.6 [with a flag](../../administration/feature_flags.md) named `ff_limit_ssh_key_lifetime`. Disabled by default.
> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/346753) in GitLab 14.6.
> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/1007) in GitLab 14.7. [Feature flag `ff_limit_ssh_key_lifetime`](https://gitlab.com/gitlab-org/gitlab/-/issues/347408) removed.
Users can optionally specify a lifetime for
[SSH keys](../../user/ssh.md).
This lifetime is not a requirement, and can be set to any arbitrary number of days.
SSH keys are user credentials to access GitLab.
However, organizations with security requirements may want to enforce more protection by
requiring the regular rotation of these keys.
### Set a lifetime
Only a GitLab administrator can set a lifetime. Leaving it empty means
there are no restrictions.
To set a lifetime on how long SSH keys are valid:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand the **Account and limit** section.
1. Fill in the **Maximum allowable lifetime for SSH keys (days)** field.
1. Select **Save changes**.
Once a lifetime for SSH keys is set, GitLab:
- Requires users to set an expiration date that is no later than the allowed lifetime on new
SSH keys.
- Applies the lifetime restriction to existing SSH keys. Keys with no expiry or a lifetime
greater than the maximum immediately become invalid.
NOTE:
When a user's SSH key becomes invalid they can delete and re-add the same key again.
## Limit the lifetime of access tokens **(ULTIMATE SELF)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3649) in GitLab 12.6.
Users can optionally specify a maximum lifetime in days for
access tokens, this includes [personal](../../user/profile/personal_access_tokens.md),
[group](../../user/group/settings/group_access_tokens.md), and [project](../../user/project/settings/project_access_tokens.md) access tokens.
This lifetime is not a requirement, and can be set to any value greater than 0 and less than or equal to 365. If this setting is left blank, the default allowable lifetime of access tokens is 365 days.
Access tokens are the only tokens needed for programmatic access to GitLab.
However, organizations with security requirements may want to enforce more protection by
requiring the regular rotation of these tokens.
### Set a lifetime
Only a GitLab administrator can set a lifetime. Leaving it empty means
there are no restrictions.
To set a lifetime on how long access tokens are valid:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand the **Account and limit** section.
1. Fill in the **Maximum allowable lifetime for access tokens (days)** field.
1. Select **Save changes**.
Once a lifetime for access tokens is set, GitLab:
- Applies the lifetime for new personal access tokens, and require users to set an expiration date
and a date no later than the allowed lifetime.
- After three hours, revoke old tokens with no expiration date or with a lifetime longer than the
allowed lifetime. Three hours is given to allow administrators to change the allowed lifetime,
or remove it, before revocation takes place.
## Disable user profile name changes **(PREMIUM SELF)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24605) in GitLab 12.7.
To maintain integrity of user details in [Audit Events](../../administration/audit_events.md), GitLab administrators can choose to disable a user's ability to change their profile name.
To do this:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**.
1. Select the **Prevent users from changing their profile name** checkbox.
NOTE:
When this ability is disabled, GitLab administrators can still use the
[Admin Area](../../administration/admin_area.md#administering-users) or the
[API](../../api/users.md#user-modification) to update usernames.
## Prevent new users from creating top-level groups
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/367754) in GitLab 15.5.
By default, new users can create top-level groups. GitLab administrators can prevent new users from creating top-level groups:
- In GitLab 15.5 and later, using either:
- The GitLab UI using the steps in this section.
- The [application setting API](../../api/settings.md#change-application-settings).
- In GitLab 15.4 and earlier, a [configuration file](../../administration/user_settings.md#use-configuration-files-to-prevent-new-users-from-creating-top-level-groups).
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**.
1. Clear the **Allow new users to create top-level groups** checkbox.
## Set profiles of new users to private by default
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/231301) in GitLab 15.8.
By default, newly created users have a public profile. GitLab administrators can set new users to have a private profile by default:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**.
1. Select the **Make new users' profiles private by default** checkbox.
## Prevent users from deleting their accounts **(PREMIUM SELF)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26053) in GitLab 16.1 [with a flag](../../administration/feature_flags.md) named `deleting_account_disabled_for_users`. Enabled by default.
By default, users can delete their own accounts. GitLab administrators can prevent
users from deleting their own accounts:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**.
1. Clear the **Allows users to delete their own accounts** checkbox.
## Troubleshooting
### 413 Request Entity Too Large
When attaching a file to a comment or reply in GitLab displays a `413 Request Entity Too Large`
error, the [max attachment size](#max-attachment-size)
is probably larger than the web server's allowed value.
To increase the max attachment size to 200 MB in a
[Linux package](https://docs.gitlab.com/omnibus/) install, you may need to
add the line below to `/etc/gitlab/gitlab.rb` before increasing the max attachment size:
```ruby
nginx['client_max_body_size'] = "200m"
```
### This repository has exceeded its size limit
If you receive intermittent push errors in your [Rails exceptions log](../../administration/logs/index.md#exceptions_jsonlog), like this:
```plaintext
Your push has been rejected, because this repository has exceeded its size limit.
```
[Housekeeping](../../administration/housekeeping.md) tasks may be causing your repository size to grow.
To resolve this problem, either of these options helps in the short- to middle-term:
- Increase the [repository size limit](#repository-size-limit).
- [Reduce the repository size](../../user/project/repository/reducing_the_repo_size_using_git.md).

2
doc/administration/user_settings.md
View File

@ -14,7 +14,7 @@ By default, new users can create top-level groups. To disable new users'
ability to create top-level groups (does not affect existing users' setting), GitLab administrators can modify this setting:
- In GitLab 15.5 and later, using either:
- The [GitLab UI](../user/admin_area/settings/account_and_limit_settings.md#prevent-new-users-from-creating-top-level-groups).
- The [GitLab UI](../administration/settings/account_and_limit_settings.md#prevent-new-users-from-creating-top-level-groups).
- The [application setting API](../api/settings.md#change-application-settings).
- In GitLab 15.4 and earlier, in a configuration file by following the steps in this section.

3
doc/api/graphql/reference/index.md
View File

@ -24568,6 +24568,7 @@ Represents a progress widget.
| ---- | ---- | ----------- |
| <a id="workitemwidgetprogressprogress"></a>`progress` | [`Int`](#int) | Progress of the work item. |
| <a id="workitemwidgetprogresstype"></a>`type` | [`WorkItemWidgetType`](#workitemwidgettype) | Widget type. |
| <a id="workitemwidgetprogressupdatedat"></a>`updatedAt` | [`Time`](#time) | Timestamp of last progress update. |
### `WorkItemWidgetRequirementLegacy`
@ -29477,7 +29478,7 @@ A time-frame defined as a closed inclusive range of two dates.
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="workitemwidgetprogressinputprogress"></a>`progress` | [`Int!`](#int) | Progress of the work item. |
| <a id="workitemwidgetprogressinputcurrentvalue"></a>`currentValue` | [`Int!`](#int) | Current progress value of the work item. |
### `WorkItemWidgetStartAndDueDateUpdateInput`

4
doc/api/users.md
View File

@ -510,7 +510,7 @@ over `password`. In addition, `reset_password` and
NOTE:
From [GitLab 12.1](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/29888/), `private_profile` defaults to `false`.
From [GitLab 15.8](https://gitlab.com/gitlab-org/gitlab/-/issues/231301), `private_profile` defaults to the value determined by [this](../user/admin_area/settings/account_and_limit_settings.md#set-profiles-of-new-users-to-private-by-default) setting.
From [GitLab 15.8](https://gitlab.com/gitlab-org/gitlab/-/issues/231301), `private_profile` defaults to the value determined by [this](../administration/settings/account_and_limit_settings.md#set-profiles-of-new-users-to-private-by-default) setting.
NOTE:
From [GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/35604), `bio` defaults to `""` instead of `null`.
@ -541,7 +541,7 @@ Parameters:
| `note` | No | Administrator notes for this user |
| `organization` | No | Organization name |
| `password` | No | Password |
| `private_profile` | No | User's profile is private - true or false. The default value is determined by [this](../user/admin_area/settings/account_and_limit_settings.md#set-profiles-of-new-users-to-private-by-default) setting. |
| `private_profile` | No | User's profile is private - true or false. The default value is determined by [this](../administration/settings/account_and_limit_settings.md#set-profiles-of-new-users-to-private-by-default) setting. |
| `projects_limit` | No | Number of projects user can create |
| `provider` | No | External provider name |
| `reset_password` | No | Send user password reset link - true or false(default) |

5
doc/development/testing_guide/end_to_end/rspec_metadata_tests.md
View File

@ -15,7 +15,7 @@ This is a partial list of the [RSpec metadata](https://rspec.info/features/3-12/
|-----------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `:elasticsearch` | The test requires an Elasticsearch service. It is used by the [instance-level scenario](https://gitlab.com/gitlab-org/gitlab-qa#definitions) [`Test::Integration::Elasticsearch`](https://gitlab.com/gitlab-org/gitlab/-/blob/72b62b51bdf513e2936301cb6c7c91ec27c35b4d/qa/qa/ee/scenario/test/integration/elasticsearch.rb) to include only tests that require Elasticsearch. |
| `:except` | The test is to be run in their typical execution contexts _except_ as specified. See [test execution context selection](execution_context_selection.md) for more information. |
| `:feature_flag` | The test uses a feature flag and therefore requires an administrator account to run. When `scope` is set to `:global`, the test will be skipped on all live .com environments. Otherwise, it will be skipped only on Canary, Production, and Pre-production. See [testing with feature flags](../../../development/testing_guide/end_to_end/feature_flags.md) for more details. |
| `:feature_flag` | The test uses a feature flag and therefore requires an administrator account to run. When `scope` is set to `:global`, the test will be skipped on all live .com environments. Otherwise, it will be skipped only on Canary, Production, and Pre-production. See [testing with feature flags](../../../development/testing_guide/end_to_end/feature_flags.md) for more details. |
| `:framework` | The test makes sanity assertions around the QA framework itself |
| `:geo` | The test requires two GitLab Geo instances - a primary and a secondary - to be spun up. |
| `:gitaly_cluster` | The test runs against a GitLab instance where repositories are stored on redundant Gitaly nodes behind a Praefect node. All nodes are [separate containers](../../../administration/gitaly/praefect.md#requirements). Tests that use this tag have a longer setup time since there are three additional containers that need to be started. |
@ -33,10 +33,11 @@ This is a partial list of the [RSpec metadata](https://rspec.info/features/3-12/
| `:mattermost` | The test requires a GitLab Mattermost service on the GitLab instance. |
| `:metrics` | The test requires a GitLab instance where [dedicated metrics exporters](../../../administration/monitoring/prometheus/web_exporter.md) are running alongside Puma and Sidekiq. |
| `:mixed_env` | The test should only be executed in environments that have a paired canary version available through traffic routing based on the existence of the `gitlab_canary=true` cookie. Tests in this category are switching the cookie mid-test to validate mixed deployment environments. |
| `:oauth` | The test uses and external OmniAuth provider to log in to GitLab |
| `:object_storage` | The test requires a GitLab instance to be configured to use multiple [object storage types](../../../administration/object_storage.md). Uses MinIO as the object storage server. |
| `:only` | The test is only to be run in specific execution contexts. See [test execution context selection](execution_context_selection.md) for more information. |
| `:orchestrated` | The GitLab instance under test may be [configured by `gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/docs/what_tests_can_be_run.md#orchestrated-tests) to be different to the default GitLab configuration, or `gitlab-qa` may launch additional services in separate Docker containers, or both. Tests tagged with `:orchestrated` are excluded when testing environments where we can't dynamically modify the GitLab configuration (for example, Staging). | |
| `:product_group` | Specifies what product group the test belongs to. See [Product sections, stages, groups, and categories](https://about.gitlab.com/handbook/product/categories/) for the comprehensive groups list. |
| `:product_group` | Specifies what product group the test belongs to. See [Product sections, stages, groups, and categories](https://about.gitlab.com/handbook/product/categories/) for the comprehensive groups list. |
| `:quarantine` | The test has been [quarantined](https://about.gitlab.com/handbook/engineering/quality/quality-engineering/debugging-qa-test-failures/#quarantining-tests), runs in a separate job that only includes quarantined tests, and is allowed to fail. The test is skipped in its regular job so that if it fails it doesn't hold up the pipeline. Note that you can also [quarantine a test only when it runs in a specific context](execution_context_selection.md#quarantine-a-test-for-a-specific-environment). |
| `:relative_url` | The test requires a GitLab instance to be installed under a [relative URL](../../../install/relative_url.md). |
| `:reliable` | The test has been [promoted to a reliable test](https://about.gitlab.com/handbook/engineering/quality/quality-engineering/reliable-tests/#promoting-an-existing-test-to-reliable) meaning it passes consistently in all pipelines, including merge requests. |

1
doc/raketasks/index.md
View File

@ -32,7 +32,6 @@ The following Rake tasks are available for use with GitLab:
| [Integrity checks](../administration/raketasks/check.md) | Check the integrity of repositories, files, LDAP, and more. |
| [LDAP maintenance](../administration/raketasks/ldap.md) | [LDAP](../administration/auth/ldap/index.md)-related tasks. |
| [List repositories](list_repos.md) | List all GitLab-managed Git repositories on disk. |
| [Migrate snippets to Git](migrate_snippets.md) | Migrate GitLab Snippets to Git repositories, and show the migration status. |
| [Praefect Rake tasks](../administration/raketasks/praefect.md) | [Praefect](../administration/gitaly/praefect.md)-related tasks. |
| [Project import/export](../administration/raketasks/project_import_export.md) | Prepare for [project exports and imports](../user/project/settings/import_export.md). |
| [Sidekiq job migration](../administration/sidekiq/sidekiq_job_migration.md) | Migrate Sidekiq jobs scheduled for future dates to a new queue. |

104
doc/raketasks/migrate_snippets.md
View File

@ -1,101 +1,11 @@
---
stage: Create
group: IDE
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
redirect_to: 'index.md'
remove_date: '2023-10-13'
---
# Migrate to versioned snippets Rake tasks **(FREE SELF)**
This document was moved to [another location](index.md).
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/215861) in GitLab 13.0.
In GitLab 13.0, [GitLab Snippets are backed by Git repositories](../user/snippets.md#versioned-snippets).
Snippet content is stored in the repository, and users can update it directly through Git.
Nevertheless, existing GitLab Snippets must be migrated to this new feature.
For each snippet:
- A new repository is created.
- A file is created in the repository, using the snippet filename.
- The snippet is committed to the repository.
GitLab performs this migration through a background migration
when the GitLab instance is upgraded to 13.0 or a higher version.
However, if the migration fails for any of the snippets, they must be migrated individually.
The following Rake tasks help with that process.
## Migrate specific snippets to Git
In case you want to migrate a range of snippets, run the tasks as described below.
For Omnibus installations, run:
```shell
sudo gitlab-rake gitlab:snippets:migrate SNIPPET_IDS=1,2,3,4
```
For installations from source code, run:
```shell
bundle exec rake gitlab:snippets:migrate SNIPPET_IDS=1,2,3,4
```
There is a default limit (100) to the number of ids supported in the migration
process. You can modify this limit by using the environment variable `LIMIT`.
```shell
sudo gitlab-rake gitlab:snippets:migrate SNIPPET_IDS=1,2,3,4 LIMIT=50
```
For installations from source code, run:
```shell
bundle exec rake gitlab:snippets:migrate SNIPPET_IDS=1,2,3,4 LIMIT=50
```
## Show whether the snippet background migration is running
In case you want to check the status of the snippet background migration,
whether it is running or not, you can use the following task.
For Omnibus installations, run:
```shell
sudo gitlab-rake gitlab:snippets:migration_status
```
For installations from source code, run:
```shell
bundle exec rake gitlab:snippets:migration_status RAILS_ENV=production
```
## List non-migrated snippets
With the following task, you can get the ids of all of the snippets
that haven't been migrated yet or failed to migrate.
For Omnibus installations, run:
```shell
sudo gitlab-rake gitlab:snippets:list_non_migrated
```
For installations from source code, run:
```shell
bundle exec rake gitlab:snippets:list_non_migrated RAILS_ENV=production
```
As the number of non-migrated snippets can be large, we limit
by default the size of the number of ids returned to 100. You can
modify this limit by using the environment variable `LIMIT`.
```shell
sudo gitlab-rake gitlab:snippets:list_non_migrated LIMIT=200
```
For installations from source code, run:
```shell
bundle exec rake gitlab:snippets:list_non_migrated RAILS_ENV=production LIMIT=200
```
<!-- This redirect file can be deleted after <2023-10-13>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

4
doc/security/two_factor_authentication.md
View File

@ -140,7 +140,7 @@ sudo -u git -H bundle exec rake gitlab:two_factor:disable_for_all_users RAILS_EN
> - Push notification support [introduced](https://gitlab.com/gitlab-org/gitlab-shell/-/issues/506) in GitLab 15.3.
FLAG:
On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../administration/feature_flags.md) named `two_factor_for_cli`. On GitLab.com, this feature is not available. The feature is not ready for production use. This feature flag also affects [session duration for Git Operations when 2FA is enabled](../user/admin_area/settings/account_and_limit_settings.md#customize-session-duration-for-git-operations-when-2fa-is-enabled).
On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../administration/feature_flags.md) named `two_factor_for_cli`. On GitLab.com, this feature is not available. The feature is not ready for production use. This feature flag also affects [session duration for Git Operations when 2FA is enabled](../administration/settings/account_and_limit_settings.md#customize-session-duration-for-git-operations-when-2fa-is-enabled).
You can enforce 2FA for [Git over SSH operations](../development/gitlab_shell/features.md#git-operations). However, you should use
[ED25519_SK](../user/ssh.md#ed25519_sk-ssh-keys) or [ECDSA_SK](../user/ssh.md#ecdsa_sk-ssh-keys) SSH keys instead. 2FA is enforced for Git operations only, and internal commands such as [`personal_access_token`](../development/gitlab_shell/features.md#personal-access-token) are excluded.
@ -165,7 +165,7 @@ SSH key.
2FA does not protect users with compromised *private* SSH keys.
Once an OTP is verified, anyone can run Git over SSH with that private SSH key for
the configured [session duration](../user/admin_area/settings/account_and_limit_settings.md#customize-session-duration-for-git-operations-when-2fa-is-enabled).
the configured [session duration](../administration/settings/account_and_limit_settings.md#customize-session-duration-for-git-operations-when-2fa-is-enabled).
<!-- ## Troubleshooting

2
doc/subscriptions/bronze_starter.md
View File

@ -84,7 +84,7 @@ the tiers are no longer mentioned in GitLab documentation:
- Reference Architecture information:
- [Zero downtime upgrades](../administration/reference_architectures/index.md#zero-downtime-upgrades)
- Repositories:
- [Repository size limit](../user/admin_area/settings/account_and_limit_settings.md#repository-size-limit)
- [Repository size limit](../administration/settings/account_and_limit_settings.md#repository-size-limit)
- Repository mirroring:
- [Pull mirroring](../user/project/repository/mirror/pull.md) outside repositories in a GitLab repository
- [Overwrite diverged branches](../user/project/repository/mirror/pull.md#overwrite-diverged-branches)

24
doc/update/index.md
View File

@ -162,22 +162,14 @@ cannot guarantee that upgrading between major versions is seamless.
A *major* upgrade requires the following steps:
1. Start by identifying a [supported upgrade path](#upgrade-paths). This is essential for a successful *major* version upgrade.
1. Upgrade to the latest minor version of the preceding major version.
1. Upgrade to the "dot zero" release of the next major version (`X.0.Z`).
1. Optional. Follow the [upgrade path](#upgrade-paths), and proceed with upgrading to newer releases of that major version.
It's also important to ensure that any [background migrations have been fully completed](background_migrations.md)
before upgrading to a new major version.
If you have enabled the [Elasticsearch integration](../integration/advanced_search/elasticsearch.md) **(PREMIUM SELF)**, then
[ensure all advanced search migrations are completed](#checking-for-pending-advanced-search-migrations) in the last minor version in
your current version
before proceeding with the major version upgrade.
If your GitLab instance has any runners associated with it, it is very
important to upgrade GitLab Runner to match the GitLab minor version that was
upgraded to. This is to ensure [compatibility with GitLab versions](https://docs.gitlab.com/runner/#gitlab-runner-versions).
1. Identify a [supported upgrade path](#upgrade-paths).
1. Ensure that any [background migrations have been fully completed](background_migrations.md)
before upgrading to a new major version.
1. If you have enabled the [Elasticsearch integration](../integration/advanced_search/elasticsearch.md), then
before proceeding with the major version upgrade, [ensure that all advanced search migrations are completed](#checking-for-pending-advanced-search-migrations).
1. If your GitLab instance has any runners associated with it, it is very
important to upgrade them to match the current GitLab version. This ensures
[compatibility with GitLab versions](https://docs.gitlab.com/runner/#gitlab-runner-versions).
## Upgrade paths

402
doc/user/admin_area/settings/account_and_limit_settings.md
View File

@ -1,399 +1,11 @@
---
stage: Create
group: Source Code
info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments"
type: reference
redirect_to: '../../../administration/settings/account_and_limit_settings.md'
remove_date: '2023-10-12'
---
# Account and limit settings **(FREE SELF)**
This document was moved to [another location](../../../administration/settings/account_and_limit_settings.md).
## Default projects limit
You can configure the default maximum number of projects new users can create in their
personal namespace. This limit affects only new user accounts created after you change
the setting. This setting is not retroactive for existing users, but you can separately edit
the [project limits for existing users](#projects-limit-for-a-user).
To configure the maximum number of projects in personal namespaces for new users:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**.
1. Increase or decrease that **Default projects limit** value.
If you set **Default projects limit** to 0, users are not allowed to create projects
in their users personal namespace. However, projects can still be created in a group.
### Projects limit for a user
You can edit a specific user, and change the maximum number of projects this user
can create in their personal namespace:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Overview** > **Users**.
1. From the list of users, select a user.
1. Select **Edit**.
1. Increase or decrease the **Projects limit** value.
## Max attachment size
> [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/20061) from 10 MB to 100 MB in GitLab 15.7.
The maximum file size for attachments in GitLab comments and replies is 100 MB.
To change the maximum attachment size:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**.
1. Increase or decrease by changing the value in **Maximum attachment size (MB)**.
If you choose a size larger than the configured value for the web server,
you may receive errors. Read the [troubleshooting section](#troubleshooting) for more
details.
For GitLab.com repository size limits, read [accounts and limit settings](../../gitlab_com/index.md#account-and-limit-settings).
## Max push size
You can change the maximum push size for your instance:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**.
1. Increase or decrease by changing the value in **Maximum push size (MB)**.
For GitLab.com push size limits, read [accounts and limit settings](../../gitlab_com/index.md#account-and-limit-settings).
NOTE:
When you [add files to a repository](../../project/repository/web_editor.md#create-a-file)
through the web UI, the maximum **attachment** size is the limiting factor,
because the [web server](../../../development/architecture.md#components)
must receive the file before GitLab can generate the commit.
Use [Git LFS](../../../topics/git/lfs/index.md) to add large files to a repository.
## Max export size
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86124) in GitLab 15.0.
To modify the maximum file size for exports in GitLab:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**, then expand **Account and limit**.
1. Increase or decrease by changing the value in **Maximum export size (MB)**.
## Max import size
> [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/251106) from 50 MB to unlimited in GitLab 13.8.
To modify the maximum file size for imports in GitLab:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**.
1. Increase or decrease by changing the value in **Maximum import size (MB)**.
This setting applies only to repositories
[imported from a GitLab export file](../../project/settings/import_export.md#import-a-project-and-its-data).
If you choose a size larger than the configured value for the web server,
you may receive errors. See the [troubleshooting section](#troubleshooting) for more
details.
For GitLab.com repository size limits, read [accounts and limit settings](../../gitlab_com/index.md#account-and-limit-settings).
## Personal access token prefix
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20968) in GitLab 13.7.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/342327) in GitLab 14.5, a default prefix.
You can specify a prefix for personal access tokens. You might use a prefix
to find tokens more quickly, or for use with automation tools.
The default prefix is `glpat-` but administrators can change it.
[Project access tokens](../../project/settings/project_access_tokens.md) and
[group access tokens](../../group/settings/group_access_tokens.md) also inherit this prefix.
### Set a prefix
To change the default global prefix:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand the **Account and limit** section.
1. Fill in the **Personal Access Token prefix** field.
1. Select **Save changes**.
You can also configure the prefix by using the
[settings API](../../../api/settings.md).
## Repository size limit **(PREMIUM SELF)**
Repositories in your GitLab instance can grow quickly, especially if you are
using LFS. Their size can grow exponentially, rapidly consuming available storage.
To prevent this from happening, you can set a hard limit for your repositories' size.
This limit can be set globally, per group, or per project, with per project limits
taking the highest priority.
There are numerous use cases where you might set up a limit for repository size.
For instance, consider the following workflow:
1. Your team develops apps which require large files to be stored in
the application repository.
1. Although you have enabled [Git LFS](../../../topics/git/lfs/index.md#git-large-file-storage-lfs)
to your project, your storage has grown significantly.
1. Before you exceed available storage, you set up a limit of 10 GB
per repository.
NOTE:
For GitLab.com repository size limits, read [accounts and limit settings](../../gitlab_com/index.md#account-and-limit-settings).
### How it works
Only a GitLab administrator can set those limits. Setting the limit to `0` means
there are no restrictions.
These settings can be found in:
- Each project's settings:
1. From the Project's homepage, navigate to **Settings > General**.
1. Fill in the **Repository size limit (MB)** field in the **Naming, topics, avatar** section.
1. Select **Save changes**.
- Each group's settings:
1. From the Group's homepage, navigate to **Settings > General**.
1. Fill in the **Repository size limit (MB)** field in the **Naming, visibility** section.
1. Select **Save changes**.
- GitLab global settings:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand the **Account and limit** section.
1. Fill in the **Size limit per repository (MB)** field.
1. Select **Save changes**.
The first push of a new project, including LFS objects, is checked for size.
If the sum of their sizes exceeds the maximum allowed repository size, the push
is rejected.
NOTE:
The repository size limit includes repository files and LFS, but does not include artifacts, uploads,
wiki, packages, or snippets. The repository size limit applies to both private and public projects.
For details on manually purging files, see [reducing the repository size using Git](../../project/repository/reducing_the_repo_size_using_git.md).
## Session duration
### Customize the default session duration
You can change how long users can remain signed in without activity.
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**. The set duration is in **Session duration (minutes)**.
If [Remember me](#turn-remember-me-on-or-off) is enabled, users' sessions can remain active for an indefinite period of time.
For details, see [cookies used for sign-in](../../profile/index.md#cookies-used-for-sign-in).
### Turn **Remember me** on or off
> Ability to turn the **Remember me** setting on and off [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/369133) in GitLab 16.0.
Users can select the **Remember me** checkbox on sign-in, and their session will remain active for an indefinite period of time when accessed from that specific browser. You can turn off this setting if you need sessions to expire for security or compliance purposes. Turning off this setting will ensure users' sessions expire after the number of minutes of inactivity set when you [customize your session duration](#customize-the-default-session-duration).
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**.
1. Select or clear the **Remember me** checkbox to turn this setting on or off.
### Customize session duration for Git Operations when 2FA is enabled **(PREMIUM SELF)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/296669) in GitLab 13.9.
> - It's deployed behind a feature flag, disabled by default.
FLAG:
On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `two_factor_for_cli`. On GitLab.com, this feature is not available. This feature is not ready for production use. This feature flag also affects [2FA for Git over SSH operations](../../../security/two_factor_authentication.md#2fa-for-git-over-ssh-operations).
GitLab administrators can choose to customize the session duration (in minutes) for Git operations when 2FA is enabled. The default is 15 and this can be set to a value between 1 and 10080.
To set a limit on how long these sessions are valid:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand the **Account and limit** section.
1. Fill in the **Session duration for Git operations when 2FA is enabled (minutes)** field.
1. Select **Save changes**.
## Limit the lifetime of SSH keys **(ULTIMATE SELF)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1007) in GitLab 14.6 [with a flag](../../../administration/feature_flags.md) named `ff_limit_ssh_key_lifetime`. Disabled by default.
> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/346753) in GitLab 14.6.
> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/1007) in GitLab 14.7. [Feature flag `ff_limit_ssh_key_lifetime`](https://gitlab.com/gitlab-org/gitlab/-/issues/347408) removed.
Users can optionally specify a lifetime for
[SSH keys](../../ssh.md).
This lifetime is not a requirement, and can be set to any arbitrary number of days.
SSH keys are user credentials to access GitLab.
However, organizations with security requirements may want to enforce more protection by
requiring the regular rotation of these keys.
### Set a lifetime
Only a GitLab administrator can set a lifetime. Leaving it empty means
there are no restrictions.
To set a lifetime on how long SSH keys are valid:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand the **Account and limit** section.
1. Fill in the **Maximum allowable lifetime for SSH keys (days)** field.
1. Select **Save changes**.
Once a lifetime for SSH keys is set, GitLab:
- Requires users to set an expiration date that is no later than the allowed lifetime on new
SSH keys.
- Applies the lifetime restriction to existing SSH keys. Keys with no expiry or a lifetime
greater than the maximum immediately become invalid.
NOTE:
When a user's SSH key becomes invalid they can delete and re-add the same key again.
## Limit the lifetime of access tokens **(ULTIMATE SELF)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/3649) in GitLab 12.6.
Users can optionally specify a maximum lifetime in days for
access tokens, this includes [personal](../../profile/personal_access_tokens.md),
[group](../../group/settings/group_access_tokens.md), and [project](../../project/settings/project_access_tokens.md) access tokens.
This lifetime is not a requirement, and can be set to any value greater than 0 and less than or equal to 365. If this setting is left blank, the default allowable lifetime of access tokens is 365 days.
Access tokens are the only tokens needed for programmatic access to GitLab.
However, organizations with security requirements may want to enforce more protection by
requiring the regular rotation of these tokens.
### Set a lifetime
Only a GitLab administrator can set a lifetime. Leaving it empty means
there are no restrictions.
To set a lifetime on how long access tokens are valid:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand the **Account and limit** section.
1. Fill in the **Maximum allowable lifetime for access tokens (days)** field.
1. Select **Save changes**.
Once a lifetime for access tokens is set, GitLab:
- Applies the lifetime for new personal access tokens, and require users to set an expiration date
and a date no later than the allowed lifetime.
- After three hours, revoke old tokens with no expiration date or with a lifetime longer than the
allowed lifetime. Three hours is given to allow administrators to change the allowed lifetime,
or remove it, before revocation takes place.
## Disable user profile name changes **(PREMIUM SELF)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24605) in GitLab 12.7.
To maintain integrity of user details in [Audit Events](../../../administration/audit_events.md), GitLab administrators can choose to disable a user's ability to change their profile name.
To do this:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**.
1. Select the **Prevent users from changing their profile name** checkbox.
NOTE:
When this ability is disabled, GitLab administrators can still use the
[Admin Area](../../../administration/admin_area.md#administering-users) or the
[API](../../../api/users.md#user-modification) to update usernames.
## Prevent new users from creating top-level groups
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/367754) in GitLab 15.5.
By default, new users can create top-level groups. GitLab administrators can prevent new users from creating top-level groups:
- In GitLab 15.5 and later, using either:
- The GitLab UI using the steps in this section.
- The [application setting API](../../../api/settings.md#change-application-settings).
- In GitLab 15.4 and earlier, a [configuration file](../../../administration/user_settings.md#use-configuration-files-to-prevent-new-users-from-creating-top-level-groups).
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**.
1. Clear the **Allow new users to create top-level groups** checkbox.
## Set profiles of new users to private by default
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/231301) in GitLab 15.8.
By default, newly created users have a public profile. GitLab administrators can set new users to have a private profile by default:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**.
1. Select the **Make new users' profiles private by default** checkbox.
## Prevent users from deleting their accounts **(PREMIUM SELF)**
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26053) in GitLab 16.1 [with a flag](../../../administration/feature_flags.md) named `deleting_account_disabled_for_users`. Enabled by default.
By default, users can delete their own accounts. GitLab administrators can prevent
users from deleting their own accounts:
1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
1. Select **Admin Area**.
1. Select **Settings > General**.
1. Expand **Account and limit**.
1. Clear the **Allows users to delete their own accounts** checkbox.
## Troubleshooting
### 413 Request Entity Too Large
When attaching a file to a comment or reply in GitLab displays a `413 Request Entity Too Large`
error, the [max attachment size](#max-attachment-size)
is probably larger than the web server's allowed value.
To increase the max attachment size to 200 MB in a
[Linux package](https://docs.gitlab.com/omnibus/) install, you may need to
add the line below to `/etc/gitlab/gitlab.rb` before increasing the max attachment size:
```ruby
nginx['client_max_body_size'] = "200m"
```
### This repository has exceeded its size limit
If you receive intermittent push errors in your [Rails exceptions log](../../../administration/logs/index.md#exceptions_jsonlog), like this:
```plaintext
Your push has been rejected, because this repository has exceeded its size limit.
```
[Housekeeping](../../../administration/housekeeping.md) tasks may be causing your repository size to grow.
To resolve this problem, either of these options helps in the short- to middle-term:
- Increase the [repository size limit](#repository-size-limit).
- [Reduce the repository size](../../project/repository/reducing_the_repo_size_using_git.md).
<!-- This redirect file can be deleted after <2023-10-12>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

2
doc/user/admin_area/settings/usage_statistics.md
View File

@ -47,7 +47,7 @@ tier. Users can continue to access the features in a paid tier without sharing u
### Features available in 14.4 and later
- [Repository size limit](../settings/account_and_limit_settings.md#repository-size-limit).
- [Repository size limit](../../../administration/settings/account_and_limit_settings.md#repository-size-limit).
- [Group access restriction by IP address](../../group/access_and_permissions.md#restrict-group-access-by-ip-address).
### Features available in 16.0 and later

7
doc/user/application_security/dependency_list/index.md
View File

@ -7,10 +7,13 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Dependency list **(ULTIMATE)**
> - Application dependencies [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10075) in GitLab 12.0.
> - System dependencies [introduced](https://gitlab.com/groups/gitlab-org/-/epics/6698) in GitLab 14.6.
> - Group-level dependency list [introduced](https://gitlab.com/groups/gitlab-org/-/epics/8090) in GitLab 16.2 [with a flag](../../../administration/feature_flags.md) named `group_level_dependencies`. Disabled by default.
Use the dependency list to review your project's dependencies and key
FLAG:
On self-managed GitLab, by default the group-level dependency list is not available. To make it available, ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `group_level_dependencies`. On GitLab.com, this feature is not available.
Use the dependency list to review your project or group's dependencies and key
details about those dependencies, including their known vulnerabilities. It is a collection of dependencies in your project, including existing and new findings.
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>

4
doc/user/application_security/secret_detection/index.md
View File

@ -40,7 +40,7 @@ contains more than 100 patterns.
Most Secret Detection patterns search for specific types of secrets.
Many services add prefixes or other structural details to their secrets so they can be identified if they're leaked.
For example, GitLab [adds a `glpat-` prefix](../../admin_area/settings/account_and_limit_settings.md#personal-access-token-prefix) to project, group, and personal access tokens by default.
For example, GitLab [adds a `glpat-` prefix](../../../administration/settings/account_and_limit_settings.md#personal-access-token-prefix) to project, group, and personal access tokens by default.
To provide more reliable, high-confidence results, Secret Detection only looks for passwords or other unstructured secrets in specific contexts like URLs.
@ -621,7 +621,7 @@ The check is always on; you don't have to set it up.
Your text is checked for the following secret types:
- GitLab [personal access tokens](../../../security/token_overview.md#personal-access-tokens)
- If a [personal access token prefix](../../../user/admin_area/settings/account_and_limit_settings.md#personal-access-token-prefix) has been configured, a token using this prefix is checked.
- If a [personal access token prefix](../../../administration/settings/account_and_limit_settings.md#personal-access-token-prefix) has been configured, a token using this prefix is checked.
- GitLab [feed tokens](../../../security/token_overview.md#feed-token)
This feature is separate from Secret Detection scanning, which checks your Git repository for leaked secrets.

4
doc/user/gitlab_com/index.md
View File

@ -191,11 +191,11 @@ varies by format:
## Account and limit settings
GitLab.com has the following account limits enabled. If a setting is not listed,
the default value [is the same as for self-managed instances](../admin_area/settings/account_and_limit_settings.md):
the default value [is the same as for self-managed instances](../../administration/settings/account_and_limit_settings.md):
| Setting | GitLab.com default |
|-------------------------------|--------------------|
| [Repository size including LFS](../admin_area/settings/account_and_limit_settings.md#repository-size-limit) | 10 GB |
| [Repository size including LFS](../../administration/settings/account_and_limit_settings.md#repository-size-limit) | 10 GB |
| [Maximum import size](../project/settings/import_export.md#import-a-project-and-its-data) | 5 GB |
| Maximum attachment size | 100 MB |

6
doc/user/group/settings/group_access_tokens.md
View File

@ -25,7 +25,7 @@ Group access tokens are similar to [project access tokens](../../project/setting
and [personal access tokens](../../profile/personal_access_tokens.md), except they are
associated with a group rather than a project or user.
In self-managed instances, group access tokens are subject to the same [maximum lifetime limits](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens) as personal access tokens if the limit is set.
In self-managed instances, group access tokens are subject to the same [maximum lifetime limits](../../../administration/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens) as personal access tokens if the limit is set.
WARNING:
The ability to create group access tokens without an expiry date was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/369122) in GitLab 15.4 and [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/392855) in GitLab 16.0. In GitLab 16.0 and later, existing group access tokens without an expiry date are automatically given an expiry date 365 days later than the current date. The automatic adding of an expiry date occurs on GitLab.com during the 16.0 milestone. The automatic adding of an expiry date occurs on self-managed instances when they are upgraded to GitLab 16.0. This change is a breaking change.
@ -41,7 +41,7 @@ You can use group access tokens:
You cannot use group access tokens to create other group, project, or personal access tokens.
Group access tokens inherit the [default prefix setting](../../admin_area/settings/account_and_limit_settings.md#personal-access-token-prefix)
Group access tokens inherit the [default prefix setting](../../../administration/settings/account_and_limit_settings.md#personal-access-token-prefix)
configured for personal access tokens.
## Create a group access token using UI
@ -64,7 +64,7 @@ To create a group access token:
- The token expires on that date at midnight UTC.
- If you do not enter an expiry date, the expiry date is automatically set to 365 days later than the current date.
- By default, this date can be a maximum of 365 days later than the current date.
- An instance-wide [maximum lifetime](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens) setting can limit the maximum allowable lifetime in self-managed instances.
- An instance-wide [maximum lifetime](../../../administration/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens) setting can limit the maximum allowable lifetime in self-managed instances.
1. Select a role for the token.
1. Select the [desired scopes](#scopes-for-a-group-access-token).
1. Select **Create group access token**.

4
doc/user/profile/index.md
View File

@ -354,7 +354,7 @@ By default, you are signed out of GitLab after seven days (10080 minutes) of ina
window, whichever comes first.
GitLab administrators can
[change this default](../admin_area/settings/account_and_limit_settings.md#customize-the-default-session-duration).
[change this default](../../administration/settings/account_and_limit_settings.md#customize-the-default-session-duration).
### Stay signed in indefinitely
@ -365,7 +365,7 @@ To remain signed in indefinitely, select the **Remember me** checkbox on the Git
You remain signed in because, although the server sets a session time of one week, your browser stores a secure token
that enables automatic reauthentication.
GitLab administrators can [turn off the **Remember me** setting](../admin_area/settings/account_and_limit_settings.md#session-duration) for environments
GitLab administrators can [turn off the **Remember me** setting](../../administration/settings/account_and_limit_settings.md#session-duration) for environments
that require sessions to expire periodically for security or compliance purposes.
### Cookies used for sign-in

2
doc/user/profile/personal_access_tokens.md
View File

@ -130,7 +130,7 @@ Personal access tokens expire on the date you define, at midnight UTC.
- GitLab runs a check at 01:00 AM UTC every day to identify personal access tokens that expire in the next seven days. The owners of these tokens are notified by email.
- GitLab runs a check at 02:00 AM UTC every day to identify personal access tokens that expire on the current date. The owners of these tokens are notified by email.
- In GitLab Ultimate, administrators can
[limit the allowable lifetime of access tokens](../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens). If not set, the maximum allowable lifetime of a personal access token is 365 days.
[limit the allowable lifetime of access tokens](../../administration/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens). If not set, the maximum allowable lifetime of a personal access token is 365 days.
- In GitLab Free and Premium, the maximum allowable lifetime of a personal access token is 365 days.
## Create a personal access token programmatically **(FREE SELF)**

4
doc/user/project/repository/reducing_the_repo_size_using_git.md
View File

@ -235,8 +235,8 @@ When using repository cleanup, note:
Repository size limits:
- Can [be set by an administrator](../../admin_area/settings/account_and_limit_settings.md#account-and-limit-settings).
- Can [be set by an administrator](../../admin_area/settings/account_and_limit_settings.md) on self-managed instances.
- Can [be set by an administrator](../../../administration/settings/account_and_limit_settings.md#account-and-limit-settings).
- Can [be set by an administrator](../../../administration/settings/account_and_limit_settings.md) on self-managed instances.
- Are [set for GitLab.com](../../gitlab_com/index.md#account-and-limit-settings).
When a project has reached its size limit, you cannot:

2
doc/user/project/settings/import_export.md
View File

@ -243,7 +243,7 @@ If you have a larger project, consider [using a Rake task](../../../administrati
Administrators can set the maximum import file size one of two ways:
- With the `max_import_size` option in the [Application settings API](../../../api/settings.md#change-application-settings).
- In the [Admin Area UI](../../admin_area/settings/account_and_limit_settings.md#max-import-size).
- In the [Admin Area UI](../../../administration/settings/account_and_limit_settings.md#max-import-size).
The default is `0` (unlimited).

6
doc/user/project/settings/project_access_tokens.md
View File

@ -26,7 +26,7 @@ Use a project access token to authenticate:
Project access tokens are similar to [group access tokens](../../group/settings/group_access_tokens.md)
and [personal access tokens](../../profile/personal_access_tokens.md).
In self-managed instances, project access tokens are subject to the same [maximum lifetime limits](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens) as personal access tokens if the limit is set.
In self-managed instances, project access tokens are subject to the same [maximum lifetime limits](../../../administration/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens) as personal access tokens if the limit is set.
WARNING:
The ability to create project access tokens without expiry was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/369122) in GitLab 15.4 and [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/392855) in GitLab 16.0. In GitLab 16.0 and later, existing project access tokens without an expiry date are automatically given an expiry date of 365 days later than the current date. The automatic adding of an expiry date occurs on GitLab.com during the 16.0 milestone. The automatic adding of an expiry date occurs on self-managed instances when they are upgraded to GitLab 16.0. This change is a breaking change.
@ -39,7 +39,7 @@ You can use project access tokens:
You cannot use project access tokens to create other group, project, or personal access tokens.
Project access tokens inherit the [default prefix setting](../../admin_area/settings/account_and_limit_settings.md#personal-access-token-prefix)
Project access tokens inherit the [default prefix setting](../../../administration/settings/account_and_limit_settings.md#personal-access-token-prefix)
configured for personal access tokens.
## Create a project access token
@ -62,7 +62,7 @@ To create a project access token:
- The token expires on that date at midnight UTC.
- If you do not enter an expiry date, the expiry date is automatically set to 365 days later than the current date.
- By default, this date can be a maximum of 365 days later than the current date.
- An instance-wide [maximum lifetime](../../admin_area/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens) setting can limit the maximum allowable lifetime in self-managed instances.
- An instance-wide [maximum lifetime](../../../administration/settings/account_and_limit_settings.md#limit-the-lifetime-of-access-tokens) setting can limit the maximum allowable lifetime in self-managed instances.
1. Select a role for the token.
1. Select the [desired scopes](#scopes-for-a-project-access-token).
1. Select **Create project access token**.

6
locale/gitlab.pot
View File

@ -1946,6 +1946,9 @@ msgstr ""
msgid "AI|Explain the code from %{filePath} in human understandable language presented in Markdown format. In the response add neither original code snippet nor any title. `%{text}`. If it is not programming code, say `The selected text is not code. I am afraid this feature is for explaining code only. Would you like to ask a different question about the selected text?` and wait for another question."
msgstr ""
msgid "AI|Explain your rating (optional)"
msgstr ""
msgid "AI|Features that use third-party AI services require transmission of data, including personal data."
msgstr ""
@ -7469,6 +7472,9 @@ msgstr ""
msgid "Billings|Free groups are limited to %{number} seats."
msgstr ""
msgid "Billings|Free seats used"
msgstr ""
msgid "Billings|Free tier and trial groups can invite a maximum of 20 members per day."
msgstr ""

6
qa/qa/page/main/login.rb
View File

@ -43,6 +43,7 @@ module QA
element :github_login_button
element :oidc_login_button
element :gitlab_oauth_login_button
element :facebook_login_button
end
view 'app/views/layouts/devise.html.haml' do
@ -186,6 +187,11 @@ module QA
click_element :github_login_button
end
def sign_in_with_facebook
set_initial_password_if_present
click_element :facebook_login_button
end
def sign_in_with_saml
set_initial_password_if_present
click_element :saml_login_button

8
qa/qa/runtime/env.rb
View File

@ -286,6 +286,14 @@ module QA
ENV['QA_GITHUB_PASSWORD']
end
def facebook_username
ENV['QA_FACEBOOK_USERNAME']
end
def facebook_password
ENV['QA_FACEBOOK_PASSWORD']
end
def forker?
!!(forker_username && forker_password)
end

18
qa/qa/specs/features/browser_ui/1_manage/login/oauth_login_with_facebook_spec.rb Normal file
View File

@ -0,0 +1,18 @@
# frozen_string_literal: true
module QA
RSpec.describe 'Manage', :orchestrated, :oauth, product_group: :authentication_and_authorization do
describe 'OAuth' do
it 'logs in with Facebook credentials',
testcase: 'https://gitlab.com/gitlab-org/gitlab/-/quality/test_cases/417115' do
Runtime::Browser.visit(:gitlab, Page::Main::Login)
Page::Main::Login.perform(&:sign_in_with_facebook)
Vendor::Facebook::Page::Login.perform(&:login)
expect(page).to have_content('Welcome to GitLab')
end
end
end
end

23
qa/qa/vendor/facebook/page/login.rb vendored Normal file
View File

@ -0,0 +1,23 @@
# frozen_string_literal: true
module QA
module Vendor
module Facebook
module Page
class Login < Vendor::Page::Base
def login
fill_in 'email', with: QA::Runtime::Env.facebook_username
fill_in 'pass', with: QA::Runtime::Env.facebook_password
find('#loginbutton').click
confirm_oauth_access
end
def confirm_oauth_access
first('span', text: 'Continue as').click if has_css?('span', text: 'Continue as')
end
end
end
end
end
end

14
qa/qa/vendor/github/page/base.rb vendored
View File

@ -1,14 +0,0 @@
# frozen_string_literal: true
module QA
module Vendor
module Github
module Page
class Base
include Capybara::DSL
include Scenario::Actable
end
end
end
end
end

5
qa/qa/vendor/github/page/login.rb vendored
View File

@ -1,13 +1,10 @@
# frozen_string_literal: true
require 'capybara/dsl'
require 'benchmark'
module QA
module Vendor
module Github
module Page
class Login < Page::Base
class Login < Vendor::Page::Base
def login
fill_in 'login', with: QA::Runtime::Env.github_username
fill_in 'password', with: QA::Runtime::Env.github_password

14
qa/qa/vendor/page/base.rb vendored Normal file
View File

@ -0,0 +1,14 @@
# frozen_string_literal: true
require 'capybara/dsl'
module QA
module Vendor
module Page
class Base
include Capybara::DSL
include Scenario::Actable
end
end
end
end

14
qa/qa/vendor/saml_idp/page/base.rb vendored
View File

@ -1,14 +0,0 @@
# frozen_string_literal: true
module QA
module Vendor
module SamlIdp
module Page
class Base
include Capybara::DSL
include Scenario::Actable
end
end
end
end
end

4
qa/qa/vendor/saml_idp/page/login.rb vendored
View File

@ -1,12 +1,10 @@
# frozen_string_literal: true
require 'capybara/dsl'
module QA
module Vendor
module SamlIdp
module Page
class Login < Page::Base
class Login < Vendor::Page::Base
def login(username, password)
QA::Runtime::Logger.debug("Logging into SAMLIdp with username: #{username} and password:#{password}")

101
spec/components/pajamas/empty_state_component_spec.rb Normal file
View File

@ -0,0 +1,101 @@
# frozen_string_literal: true
require "spec_helper"
RSpec.describe Pajamas::EmptyStateComponent, type: :component, feature_category: :design_system do
let(:title) { 'Empty state title' }
let(:primary_button_link) { '#learn-more-primary' }
let(:primary_button_text) { 'Learn more' }
let(:secondary_button_link) { '#learn-more-secondary' }
let(:secondary_button_text) { 'Another action' }
let(:description) { 'Empty state description' }
let(:svg_path) { 'illustrations/empty-state/empty-projects-deleted-md.svg' }
let(:compact) { false }
let(:empty_state_options) { { id: 'empty-state-rails-component' } }
before do
render_inline described_class.new(
title: title,
svg_path: svg_path,
empty_state_options: empty_state_options,
primary_button_link: primary_button_link,
primary_button_text: primary_button_text,
secondary_button_link: secondary_button_link,
secondary_button_text: secondary_button_text,
compact: compact) do |c|
c.with_description { description } if description
end
end
describe 'default' do
it 'renders the primary action' do
expect(page).to have_link(primary_button_text, href: primary_button_link)
end
it 'renders the secondary action' do
expect(page).to have_link(secondary_button_text, href: secondary_button_link)
end
it 'renders image as illustration' do
img = page.find('img')
expect(img['src']).to eq(ActionController::Base.helpers.image_path(svg_path))
end
it 'renders title' do
h1 = page.find('h1')
expect(h1).to have_text(title)
end
it 'renders description' do
expect(find_description).to have_text(description)
end
it 'renders section with flex direction column' do
expect(find_section[:id]).to eq(empty_state_options[:id])
expect(find_section[:class]).to eq("gl-display-flex empty-state gl-text-center gl-flex-direction-column")
end
end
describe 'when compact' do
let(:compact) { true }
it 'renders section with flex direction row' do
expect(find_section[:class]).to eq("gl-display-flex empty-state gl-flex-direction-row gl-align-items-center")
end
end
describe 'when svg_path is empty' do
let(:svg_path) { '' }
it 'does not render image' do
expect(page).not_to have_selector('img')
end
end
describe 'when description is empty' do
let(:description) { nil }
it 'does not render a description' do
expect(find_description).to be_nil
end
end
describe 'with no buttons' do
let(:primary_button_text) { nil }
let(:secondary_button_text) { nil }
it 'does not render any buttons' do
expect(page).not_to have_selector('a')
end
end
def find_section
page.find('section')
end
def find_description
page.first('[data-testid="empty-state-description"]', minimum: 0)
end
end

36
spec/components/previews/pajamas/empty_state_component_preview.rb Normal file
View File

@ -0,0 +1,36 @@
# frozen_string_literal: true
module Pajamas
class EmptyStateComponentPreview < ViewComponent::Preview
# @param title text
# @param description textarea
# @param compact toggle
# @param svg_path text
# @param primary_button_text text
# @param primary_button_link text
# @param secondary_button_text text
# @param secondary_button_link text
def default(
title: "This state is empty",
description: "The title and message should be clear, concise, and explain why the user is seeing this screen.
The actions should help the user on what to do to get the real feature.",
compact: false,
svg_path: "illustrations/empty-state/empty-projects-deleted-md.svg",
primary_button_text: "Do primary action",
primary_button_link: "#learn-more-primary",
secondary_button_text: "Do secondary action",
secondary_button_link: "#learn-more-secondary")
render(Pajamas::EmptyStateComponent.new(
title: title,
svg_path: svg_path,
primary_button_text: primary_button_text,
primary_button_link: primary_button_link,
secondary_button_text: secondary_button_text,
secondary_button_link: secondary_button_link,
compact: compact
)) do |c|
c.with_description { description } if description
end
end
end
end

1
spec/factories/boards.rb
View File

@ -28,6 +28,7 @@ FactoryBot.define do
end
after(:create) do |board|
board.lists.create!(list_type: :backlog)
board.lists.create!(list_type: :closed)
end
end

1
spec/features/boards/boards_spec.rb
View File

@ -74,7 +74,6 @@ RSpec.describe 'Project issue boards', :js, feature_category: :team_planning do
let_it_be(:a_plus, reload: true) { create(:label, project: project, name: 'A+') }
let_it_be(:list1, reload: true) { create(:list, board: board, label: planning, position: 0) }
let_it_be(:list2, reload: true) { create(:list, board: board, label: development, position: 1) }
let_it_be(:backlog_list, reload: true) { create(:backlog_list, board: board) }
let_it_be(:confidential_issue, reload: true) { create(:labeled_issue, :confidential, project: project, author: user, labels: [planning], relative_position: 9) }
let_it_be(:issue1, reload: true) { create(:labeled_issue, project: project, title: 'aaa', description: '111', assignees: [user], labels: [planning], relative_position: 8) }

9
spec/features/boards/new_issue_spec.rb
View File

@ -5,7 +5,6 @@ require 'spec_helper'
RSpec.describe 'Issue Boards new issue', :js, feature_category: :team_planning do
let_it_be(:project) { create(:project, :public) }
let_it_be(:board) { create(:board, project: project) }
let_it_be(:backlog_list) { create(:backlog_list, board: board) }
let_it_be(:label) { create(:label, project: project, name: 'Label 1') }
let_it_be(:list) { create(:list, board: board, label: label, position: 0) }
let_it_be(:user) { create(:user) }
@ -179,8 +178,6 @@ RSpec.describe 'Issue Boards new issue', :js, feature_category: :team_planning d
end
context 'when backlog list already exists' do
let_it_be(:backlog_list) { create(:backlog_list, board: group_board) }
it 'does not display new issue button in open list' do
expect(first('.board')).not_to have_button('Create new issue')
end
@ -204,14 +201,16 @@ RSpec.describe 'Issue Boards new issue', :js, feature_category: :team_planning d
end
context 'when backlog does not exist' do
before do
group_board.lists.backlog.delete_all
end
it 'display new issue button in label list' do
expect(board_list_header).to have_button('Create new issue')
end
end
context 'project select dropdown' do
let_it_be(:backlog_list) { create(:backlog_list, board: group_board) }
before do
page.within(board_list_header) do
click_button 'Create new issue'

1
spec/features/boards/sidebar_labels_in_namespaces_spec.rb
View File

@ -12,7 +12,6 @@ RSpec.describe 'Issue boards sidebar labels select', :js, feature_category: :tea
context 'group boards' do
context 'in the top-level group board' do
let_it_be(:group_board) { create(:board, group: group) }
let_it_be(:board_list) { create(:backlog_list, board: group_board) }
before do
stub_feature_flags(apollo_boards: false)

2
spec/features/boards/user_adds_lists_to_board_spec.rb
View File

@ -13,8 +13,6 @@ RSpec.describe 'User adds lists', :js, feature_category: :team_planning do
let_it_be(:group_label) { create(:group_label, group: group) }
let_it_be(:project_label) { create(:label, project: project) }
let_it_be(:group_backlog_list) { create(:backlog_list, board: group_board) }
let_it_be(:project_backlog_list) { create(:backlog_list, board: project_board) }
let_it_be(:backlog) { create(:group_label, group: group, name: 'Backlog') }
let_it_be(:closed) { create(:group_label, group: group, name: 'Closed') }

2
spec/features/boards/user_visits_board_spec.rb
View File

@ -62,7 +62,6 @@ RSpec.describe 'User visits issue boards', :js, feature_category: :team_planning
context "project boards" do
stub_feature_flags(apollo_boards: false)
let_it_be(:board) { create_default(:board, project: project) }
let_it_be(:backlog_list) { create_default(:backlog_list, board: board) }
let(:board_path) { project_boards_path(project, params) }
@ -72,7 +71,6 @@ RSpec.describe 'User visits issue boards', :js, feature_category: :team_planning
context "group boards" do
stub_feature_flags(apollo_boards: false)
let_it_be(:board) { create_default(:board, group: group) }
let_it_be(:backlog_list) { create_default(:backlog_list, board: board) }
let(:board_path) { group_boards_path(group, params) }

1
spec/features/groups/board_spec.rb
View File

@ -50,7 +50,6 @@ RSpec.describe 'Group Boards', feature_category: :team_planning do
context "when user is a Reporter in one of the group's projects", :js do
let_it_be(:board) { create(:board, group: group) }
let_it_be(:backlog_list) { create(:backlog_list, board: board) }
let_it_be(:group_label1) { create(:group_label, title: "bug", group: group) }
let_it_be(:group_label2) { create(:group_label, title: "dev", group: group) }
let_it_be(:list1) { create(:list, board: board, label: group_label1, position: 0) }

2
spec/graphql/resolvers/board_lists_resolver_spec.rb
View File

@ -21,6 +21,7 @@ RSpec.describe Resolvers::BoardListsResolver do
end
it 'does not create the backlog list' do
board.lists.backlog.delete_all
lists = resolve_board_lists
expect(lists.count).to eq 1
@ -35,7 +36,6 @@ RSpec.describe Resolvers::BoardListsResolver do
context 'when authorized' do
let!(:label_list) { create(:list, board: board, label: label) }
let!(:backlog_list) { create(:backlog_list, board: board) }
it 'returns a list of board lists' do
lists = resolve_board_lists

71
spec/migrations/deduplicate_inactive_alert_integrations_spec.rb Normal file
View File

@ -0,0 +1,71 @@
# frozen_string_literal: true
require 'spec_helper'
require_migration!
RSpec.describe DeduplicateInactiveAlertIntegrations, feature_category: :incident_management do
let!(:namespace_class) { table(:namespaces) }
let!(:project_class) { table(:projects) }
let!(:integration_class) { table(:alert_management_http_integrations) }
let!(:namespace_0) { namespace_class.create!(name: 'namespace1', path: 'namespace1') }
let!(:namespace_1) { namespace_class.create!(name: 'namespace2', path: 'namespace2') }
let!(:namespace_2) { namespace_class.create!(name: 'namespace3', path: 'namespace3') }
let!(:project_with_inactive_duplicate) { create_project(namespace_0, namespace_0) }
let!(:project_with_multiple_duplicates) { create_project(namespace_0, namespace_1) }
let!(:project_without_duplicates) { create_project(namespace_0, namespace_2) }
let!(:integrations) do
[
create_integration(project_with_inactive_duplicate, 'default'),
create_integration(project_with_inactive_duplicate, 'other'),
create_integration(project_with_inactive_duplicate, 'other', active: false),
create_integration(project_with_multiple_duplicates, 'default', active: false),
create_integration(project_with_multiple_duplicates, 'default', active: false),
create_integration(project_with_multiple_duplicates, 'other', active: false),
create_integration(project_with_multiple_duplicates, 'other'),
create_integration(project_without_duplicates, 'default'),
create_integration(project_without_duplicates, 'other', active: false)
]
end
describe '#up' do
it 'updates the endpoint identifier of duplicate inactive integrations' do
expect { migrate! }
.to not_change { integrations[0].reload }
.and not_change { integrations[1].reload }
.and not_change { integrations[6].reload }
.and not_change { integrations[7].reload }
.and not_change { integrations[8].reload }
expect { integrations[2].reload }.to raise_error(ActiveRecord::RecordNotFound)
expect { integrations[3].reload }.to raise_error(ActiveRecord::RecordNotFound)
expect { integrations[4].reload }.to raise_error(ActiveRecord::RecordNotFound)
expect { integrations[5].reload }.to raise_error(ActiveRecord::RecordNotFound)
endpoints = integration_class.pluck(:endpoint_identifier, :project_id)
expect(endpoints.uniq).to match_array(endpoints)
end
end
private
def create_integration(project, endpoint_identifier, active: true)
integration_class.create!(
project_id: project.id,
endpoint_identifier: endpoint_identifier,
active: active,
encrypted_token_iv: 'iv',
encrypted_token: 'token',
name: "HTTP Integration - #{endpoint_identifier}"
)
end
def create_project(namespace, project_namespace)
project_class.create!(
namespace_id: namespace.id,
project_namespace_id: project_namespace.id
)
end
end

4
spec/models/alert_management/http_integration_spec.rb
View File

@ -29,13 +29,13 @@ RSpec.describe AlertManagement::HttpIntegration, feature_category: :incident_man
# Uniqueness spec saves integration with `validate: false` otherwise.
subject { create(:alert_management_http_integration, :legacy) }
it { is_expected.to validate_uniqueness_of(:endpoint_identifier).scoped_to(:project_id, :active) }
it { is_expected.to validate_uniqueness_of(:endpoint_identifier).scoped_to(:project_id) }
end
context 'when inactive' do
subject { create(:alert_management_http_integration, :legacy, :inactive) }
it { is_expected.not_to validate_uniqueness_of(:endpoint_identifier).scoped_to(:project_id, :active) }
it { is_expected.to validate_uniqueness_of(:endpoint_identifier).scoped_to(:project_id) }
end
context 'payload_attribute_mapping' do

2
spec/requests/api/graphql/boards/board_list_issues_query_spec.rb
View File

@ -19,7 +19,7 @@ RSpec.describe 'get board lists', feature_category: :team_planning do
let(:confidential) { false }
let(:board_parent_type) { board_parent.class.to_s.downcase }
let(:board_data) { graphql_data[board_parent_type]['boards']['nodes'][0] }
let(:lists_data) { board_data['lists']['nodes'][0] }
let(:lists_data) { board_data['lists']['nodes'][1] }
let(:issues_data) { lists_data['issues']['nodes'] }
let(:issue_params) { { filters: { label_name: label2.title, confidential: confidential }, first: 3 } }

2
spec/requests/api/graphql/boards/board_lists_query_spec.rb
View File

@ -90,7 +90,7 @@ RSpec.describe 'get board lists', feature_category: :team_planning do
context 'when using default sorting' do
let!(:label_list) { create(:list, board: board, label: label, position: 10) }
let!(:label_list2) { create(:list, board: board, label: label2, position: 2) }
let!(:backlog_list) { create(:backlog_list, board: board) }
let(:backlog_list) { board.lists.find_by(list_type: :backlog) }
let(:closed_list) { board.lists.find_by(list_type: :closed) }
let(:lists) { [backlog_list, label_list2, label_list, closed_list] }

12
spec/requests/api/groups_spec.rb
View File

@ -1092,14 +1092,14 @@ RSpec.describe API::Groups, feature_category: :groups_and_projects do
end
context 'with owned' do
let(:group) { create(:group) }
let_it_be(:group) { create(:group) }
let(:project1) { create(:project, group: group) }
let(:project1_guest) { create(:user) }
let(:project1_owner) { create(:user) }
let(:project1_maintainer) { create(:user) }
let_it_be(:project1) { create(:project, group: group) }
let_it_be(:project1_guest) { create(:user) }
let_it_be(:project1_owner) { create(:user) }
let_it_be(:project1_maintainer) { create(:user) }
let(:project2) { create(:project, group: group) }
let_it_be(:project2) { create(:project, group: group) }
before do
project1.add_guest(project1_guest)

10
spec/services/boards/issues/list_service_spec.rb
View File

@ -20,10 +20,10 @@ RSpec.describe Boards::Issues::ListService, feature_category: :team_planning do
let_it_be(:p2) { create(:label, title: 'P2', project: project, priority: 2) }
let_it_be(:p3) { create(:label, title: 'P3', project: project, priority: 3) }
let_it_be(:backlog) { create(:backlog_list, board: board) }
let_it_be(:backlog) { board.lists.backlog.first }
let_it_be(:list1) { create(:list, board: board, label: development, position: 0) }
let_it_be(:list2) { create(:list, board: board, label: testing, position: 1) }
let_it_be(:closed) { create(:closed_list, board: board) }
let_it_be(:closed) { board.lists.closed.first }
let_it_be(:opened_issue1) { create(:labeled_issue, project: project, milestone: m1, title: 'Issue 1', labels: [bug]) }
let_it_be(:opened_issue2) { create(:labeled_issue, project: project, milestone: m2, title: 'Issue 2', labels: [p2]) }
@ -109,10 +109,10 @@ RSpec.describe Boards::Issues::ListService, feature_category: :team_planning do
let(:p2_project1) { create(:label, title: 'P2_project1', project: project1, priority: 2) }
let(:p3_project1) { create(:label, title: 'P3_project1', project: project1, priority: 3) }
let!(:backlog) { create(:backlog_list, board: board) }
let!(:backlog) { board.lists.backlog.first }
let!(:list1) { create(:list, board: board, label: development, position: 0) }
let!(:list2) { create(:list, board: board, label: testing, position: 1) }
let!(:closed) { create(:closed_list, board: board) }
let!(:closed) { board.lists.closed.first }
let!(:opened_issue1) { create(:labeled_issue, project: project, milestone: m1, title: 'Issue 1', labels: [bug]) }
let!(:opened_issue2) { create(:labeled_issue, project: project, milestone: m2, title: 'Issue 2', labels: [p2, p2_project]) }
@ -145,7 +145,6 @@ RSpec.describe Boards::Issues::ListService, feature_category: :team_planning do
context 'when the group is an ancestor' do
let(:parent) { create(:group) }
let(:group) { create(:group, parent: parent) }
let!(:backlog) { create(:backlog_list, board: board) }
let(:board) { create(:board, group: parent) }
before do
@ -161,7 +160,6 @@ RSpec.describe Boards::Issues::ListService, feature_category: :team_planning do
let_it_be(:user) { create(:user) }
let_it_be(:project) { create(:project, :empty_repo) }
let_it_be(:board) { create(:board, project: project) }
let_it_be(:backlog) { create(:backlog_list, board: board) }
let(:issue) { create(:issue, project: project, relative_position: nil) }

6
spec/services/boards/lists/list_service_spec.rb
View File

@ -9,7 +9,7 @@ RSpec.describe Boards::Lists::ListService, feature_category: :team_planning do
RSpec.shared_examples 'FOSS lists only' do
context 'when board contains a non FOSS list' do
# This scenario may happen when there used to be an EE license and user downgraded
let!(:backlog_list) { create_backlog_list(board) }
let_it_be(:backlog_list) { board.lists.backlog.first }
let_it_be(:milestone) { create(:milestone, group: group) }
let_it_be(:assignee_list) do
list = build(:list, board: board, user_id: user.id, list_type: List.list_types[:assignee], position: 0)
@ -59,9 +59,5 @@ RSpec.describe Boards::Lists::ListService, feature_category: :team_planning do
it_behaves_like 'lists list service'
it_behaves_like 'FOSS lists only'
end
def create_backlog_list(board)
create(:backlog_list, board: board)
end
end
end

4
spec/support/shared_examples/graphql/mutations/boards_list_create_shared_examples.rb
View File

@ -33,6 +33,10 @@ RSpec.shared_examples 'board lists create mutation' do
describe 'backlog list' do
let(:list_create_params) { { backlog: true } }
before do
board.lists.backlog.delete_all
end
it 'creates one and only one backlog' do
expect { subject }.to change { board.lists.backlog.count }.by(1)
expect(board.lists.backlog.first.list_type).to eq 'backlog'

2
spec/support/shared_examples/services/boards/issues_move_service_shared_examples.rb
View File

@ -54,7 +54,7 @@ RSpec.shared_examples 'issues move service' do |group|
context 'when moving to backlog' do
let(:milestone) { create(:milestone, project: project) }
let!(:backlog) { create(:backlog_list, board: board1) }
let!(:backlog) { board1.lists.backlog.first }
let(:issue) { create(:labeled_issue, project: project, labels: [bug, development, testing, regression], milestone: milestone) }
let(:params) { { board_id: board1.id, from_list_id: list2.id, to_list_id: backlog.id } }

6
spec/support/shared_examples/services/boards/lists_list_service_shared_examples.rb
View File

@ -2,7 +2,7 @@
RSpec.shared_examples 'lists list service' do
context 'when the board has a backlog list' do
let!(:backlog_list) { create_backlog_list(board) }
let(:backlog_list) { board.lists.backlog.first }
it 'does not create a backlog list' do
expect { service.execute(board) }.not_to change { board.lists.count }
@ -34,6 +34,10 @@ RSpec.shared_examples 'lists list service' do
end
context 'when the board does not have a backlog list' do
before do
board.lists.backlog.delete_all
end
it 'creates a backlog list' do
expect { service.execute(board) }.to change { board.lists.count }.by(1)
end