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 2024-04-29 00:13:14 +00:00
parent 32b1848b64
commit 05596cc7e8
52 changed files with 62 additions and 358 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
doc/administration/audit_event_reports.md
View File

@ -109,8 +109,6 @@ DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1449) in GitLab 13.4.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/285441) in GitLab 13.7.
> - Entity type `Gitlab::Audit::InstanceScope` for instance audit events [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/418185) in GitLab 16.2.
You can export the current view (including filters) of your instance audit events as a
@ -158,9 +156,6 @@ DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/536) in GitLab 13.0.
> - Impersonation session events included in group audit events in GitLab 14.8.
When a user is [impersonated](../administration/admin_area.md#user-impersonation), their actions are logged as audit events with the following additional details:
- Audit events include information about the impersonating administrator.

3
doc/administration/audit_event_streaming/graphql_api.md
View File

@ -10,9 +10,6 @@ DETAILS:
**Tier:** Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
> - API [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/332747) in GitLab 14.5 [with a flag](../feature_flags.md) named `ff_external_audit_events_namespace`. Disabled by default.
> - API [enabled on GitLab.com and by default on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/338939) in GitLab 14.7.
> - API [feature flag `ff_external_audit_events_namespace`](https://gitlab.com/gitlab-org/gitlab/-/issues/349588) removed in GitLab 14.8.
> - Custom HTTP headers API [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/361216) in GitLab 15.1 [with a flag](../feature_flags.md) named `streaming_audit_event_headers`. Disabled by default.
> - Custom HTTP headers API [enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/362941) in GitLab 15.2.
> - Custom HTTP headers API [made generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/366524) in GitLab 15.3. [Feature flag `streaming_audit_event_headers`](https://gitlab.com/gitlab-org/gitlab/-/issues/362941) removed.

1
doc/administration/audit_event_streaming/index.md
View File

@ -10,7 +10,6 @@ DETAILS:
**Tier:** Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
> - UI [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/336411) in GitLab 14.9.
> - [Subgroup events recording](https://gitlab.com/gitlab-org/gitlab/-/issues/366878) fixed in GitLab 15.2.
> - Custom HTTP headers UI [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/361630) in GitLab 15.2 [with a flag](../feature_flags.md) named `custom_headers_streaming_audit_events_ui`. Disabled by default.
> - Custom HTTP headers UI [made generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/365259) in GitLab 15.3. [Feature flag `custom_headers_streaming_audit_events_ui`](https://gitlab.com/gitlab-org/gitlab/-/issues/365259) removed.

2
doc/administration/encrypted_configuration.md
View File

@ -10,8 +10,6 @@ DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** Self-managed
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/45712) in GitLab 13.7.
GitLab can read settings for certain features from encrypted settings files. The supported features are:
- [Incoming email `user` and `password`](incoming_email.md#use-encrypted-credentials).

35
doc/administration/instance_limits.md
View File

@ -100,8 +100,6 @@ This setting limits the request rate on the Packages API per user or IP. For mor
### Git LFS
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68642) in GitLab 14.3.
This setting limits the request rate on the [Git LFS](../topics/git/lfs/index.md)
requests per user. For more information, read
[GitLab Git Large File Storage (LFS) Administration](../administration/lfs/index.md).
@ -110,9 +108,6 @@ requests per user. For more information, read
### Files API
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68561) in GitLab 14.3 [with a flag](../administration/feature_flags.md) named `files_api_throttling`. Disabled by default.
> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/75918) in GitLab 14.6. [Feature flag `files_api_throttling`](https://gitlab.com/gitlab-org/gitlab/-/issues/338903) removed.
This setting limits the request rate on the Packages API per user or IP address. For more information, read
[Files API rate limits](settings/files_api_rate_limits.md).
@ -120,8 +115,6 @@ This setting limits the request rate on the Packages API per user or IP address.
### Deprecated API endpoints
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68645) in GitLab 14.4.
This setting limits the request rate on deprecated API endpoints per user or IP address. For more information, read
[Deprecated API rate limits](settings/deprecated_api_rate_limits.md).
@ -151,8 +144,6 @@ Limit the maximum daily member invitations allowed per group hierarchy.
### Webhook rate limit
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/61151) in GitLab 13.12.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/330133) in GitLab 14.1.
> - [Limit changed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89591) from per-hook to per-top-level namespace in GitLab 15.1.
Limit the number of times a webhook can be called per minute, per top-level namespace.
@ -176,7 +167,6 @@ Set the limit to `0` to disable it.
### Search rate limit
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80631) in GitLab 14.9.
> - [Changed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/104208) in GitLab 15.9 to include issue, merge request, and epic searches in the rate limit.
> - [Changed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/118525) in GitLab 16.0 to apply rate limits to [search scopes](../user/search/index.md#global-search-scopes) for authenticated requests.
@ -331,8 +321,6 @@ See also [webhook limits for GitLab.com](../user/gitlab_com/index.md#other-limit
### Recursive webhooks
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/329743) in GitLab 14.8.
GitLab detects and blocks webhooks that are recursive or that exceed the limit
of webhooks that can be triggered from other webhooks. This enables GitLab to
continue to support workflows that use webhooks to call the API non-recursively, or that
@ -488,8 +476,6 @@ Set the limit to `0` to disable it.
### Limit the number of pipeline triggers
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/33696) in GitLab 14.6.
You can set a limit on the maximum number of pipeline triggers per project. This
limit is checked every time a new trigger is created.
@ -530,8 +516,6 @@ Plan.default.actual_limits.update!(ci_pipeline_schedules: 100)
### Limit the number of pipelines created by a pipeline schedule per day
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/323066) in GitLab 14.0.
You can limit the number of pipelines that pipeline schedules can trigger per day.
Schedules that try to run pipelines more frequently than the limit are slowed to a maximum frequency.
@ -685,12 +669,6 @@ To set a limit on your self-managed instance, use the
### Number of registered runners per scope
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321368) in GitLab 13.12. Disabled by default.
> - Enabled on GitLab.com in GitLab 14.3.
> - Enabled on self-managed in GitLab 14.4.
> - Feature flag `ci_runner_limits` removed in GitLab 14.4.
> - Feature flag `ci_runner_limits_override` removed in GitLab 14.6.
The total number of registered runners is limited at the group and project levels. Each time a new runner is registered,
GitLab checks these limits against runners that have been active in the last 3 months.
A runner's registration fails if it exceeds the limit for the scope determined by the runner registration token.
@ -716,9 +694,6 @@ Plan.default.actual_limits.update!(ci_registered_project_runners: 100)
### Maximum file size for job logs
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/276192) in GitLab 14.1, disabled by default.
> - Enabled by default and [feature flag `ci_jobs_trace_size_limit` removed](https://gitlab.com/gitlab-org/gitlab/-/issues/335259) in GitLab 14.2.
The job log file size limit in GitLab is 100 megabytes by default. Any job that exceeds the
limit is marked as failed, and dropped by the runner.
@ -736,8 +711,6 @@ continue to run, but the log is truncated when it hits the limit.
### Maximum number of active DAST profile schedules per project
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68551) in GitLab 14.3.
Limit the number of active DAST profile schedules per project. A DAST profile schedule can be active or inactive.
You can change the limit in the [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session).
@ -791,8 +764,6 @@ ApplicationSetting.update(ci_max_total_yaml_size_bytes: 20.megabytes)
### Limit dotenv variables
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321552) in GitLab 14.5.
You can set a limit on the maximum number of variables inside of a dotenv artifact.
This limit is checked every time a dotenv file is exported as an artifact.
@ -809,8 +780,6 @@ This limit is [enabled on GitLab.com](../user/gitlab_com/index.md#gitlab-cicd).
### Limit dotenv file size
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321552) in GitLab 14.5.
You can set a limit on the maximum size of a dotenv artifact. This limit is checked
every time a dotenv file is exported as an artifact.
@ -1101,8 +1070,6 @@ When asking for versions of a given NuGet package name, the GitLab package regis
## Dependency Proxy Limits
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/6396) in GitLab 14.5.
The maximum file size for an image cached in the
[Dependency Proxy](../user/packages/dependency_proxy/index.md)
varies by file type:
@ -1130,8 +1097,6 @@ Container repository tags are in the container registry and, as such, each tag d
## Project-level Secure Files API limits
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/78227) in GitLab 14.8.
The [secure files API](../api/secure_files.md) enforces the following limits:
- Files must be smaller than 5 MB.

4
doc/administration/logs/log_parsing.md
View File

@ -13,7 +13,7 @@ DETAILS:
We recommend using log aggregation and search tools like Kibana and Splunk whenever possible,
but if they are not available you can still quickly parse
[GitLab logs](../logs/index.md) in JSON format
(the default in GitLab 12.0 and later) using [`jq`](https://stedolan.github.io/jq/).
using [`jq`](https://stedolan.github.io/jq/).
NOTE:
Specifically for summarizing error events and basic usage statistics,
@ -315,7 +315,7 @@ grep "fatal: " current |
### Parsing `gitlab-shell/gitlab-shell.log`
For investigating Git calls via SSH, from [GitLab 12.10](https://gitlab.com/gitlab-org/gitlab-shell/-/merge_requests/367).
For investigating Git calls via SSH.
Find the top 20 calls by project and user:

26
doc/administration/object_storage.md
View File

@ -49,8 +49,6 @@ Specifically, GitLab has been tested by vendors and customers on a number of obj
## Configure a single storage connection for all object types (consolidated form)
> - [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4368) in GitLab 13.2.
Most types of objects, such as CI artifacts, LFS files, and upload attachments
can be saved in object storage by specifying a single credential for object
storage with multiple buckets.
@ -97,7 +95,7 @@ common set of parameters.
| `enabled` | Enable or disable object storage. |
| `proxy_download` | Set to `true` to [enable proxying all files served](#proxy-download). Option allows to reduce egress traffic as this allows clients to download directly from remote storage instead of proxying all data. |
| `connection` | Various [connection options](#configure-the-connection-settings) described below. |
| `storage_options` | Options to use when saving new objects, such as [server side encryption](#server-side-encryption-headers). Introduced in GitLab 13.3. |
| `storage_options` | Options to use when saving new objects, such as [server side encryption](#server-side-encryption-headers). |
| `objects` | [Object-specific configuration](#configure-the-parameters-of-each-object). |
For an example, see how to [use the consolidated form and Amazon S3](#full-example-using-the-consolidated-form-and-amazon-s3).
@ -149,8 +147,8 @@ gitlab_rails['artifacts_enabled'] = false
## Configure each object type to define its own storage connection (storage-specific form)
With the storage-specific form, every object defines its own object
storage connection and configuration. If you're using GitLab 13.2 and later,
you should [transition to the consolidated form](#transition-to-consolidated-form).
storage connection and configuration. You should [use the consolidated form](#transition-to-consolidated-form) instead,
except for the storage types not supported by the consolidated form.
The use of [encrypted S3 buckets](#encrypted-s3-buckets) with non-consolidated form is not supported.
You may get [ETag mismatch errors](#etag-mismatch) if you use it.
@ -160,7 +158,7 @@ For the storage-specific form,
[direct upload may become the default](https://gitlab.com/gitlab-org/gitlab/-/issues/27331)
because it does not require a shared folder.
For configuring object storage in GitLab 13.1 and earlier, _or_ for storage types not
For storage types not
supported by the consolidated form, refer to the following guides:
| Object storage type | Supported by consolidated form? |
@ -247,9 +245,6 @@ To set up an instance profile:
#### Encrypted S3 buckets
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-workhorse/-/merge_requests/466) in GitLab 13.1 for instance profiles only and [S3 default encryption](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html).
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/34460) in GitLab 13.2 for static credentials when the [consolidated form](#configure-a-single-storage-connection-for-all-object-types-consolidated-form) and [S3 default encryption](https://docs.aws.amazon.com/AmazonS3/latest/dev/bucket-encryption.html) is used.
When configured either with an instance profile or with the consolidated
form, GitLab Workhorse properly uploads files to S3
buckets that have [SSE-S3 or SSE-KMS encryption enabled by default](https://docs.aws.amazon.com/kms/latest/developerguide/services-s3.html).
@ -258,8 +253,6 @@ AWS KMS keys and SSE-C encryption are
#### Server-side encryption headers
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38240) in GitLab 13.3.
Setting a default encryption on an S3 bucket is the easiest way to
enable encryption, but you may want to
[set a bucket policy to ensure only encrypted objects are uploaded](https://repost.aws/knowledge-center/s3-bucket-store-kms-encrypted-objects).
@ -332,8 +325,6 @@ gitlab_rails['object_store']['connection'] = {
#### GCS example with ADC
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/275979) in GitLab 13.6.
Google Cloud Application Default Credentials (ADC) are typically
used with GitLab to use the default service account. This eliminates the
need to supply credentials for the instance. For example, in the consolidated form:
@ -359,8 +350,6 @@ If you use ADC, be sure that:
### Azure Blob storage
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25877) in GitLab 13.4.
Although Azure uses the word `container` to denote a collection of
blobs, GitLab standardizes on the term `bucket`. Be sure to configure
Azure container names in the `bucket` settings.
@ -757,12 +746,11 @@ To migrate existing local data to object storage see the following guides:
## Transition to consolidated form
Prior to GitLab 13.2:
In storage-specific configuration:
- Object storage configuration for all types of objects such as CI/CD artifacts, LFS
files, and upload attachments had to be configured independently.
- Object store connection parameters such as passwords and endpoint URLs had to be
duplicated for each type.
files, and upload attachments is configured independently.
- Object store connection parameters such as passwords and endpoint URLs is duplicated for each type.
For example, a Linux package installation might have the following configuration:

4
doc/administration/operations/puma.md
View File

@ -255,9 +255,7 @@ NOTE:
For Helm-based deployments, see the
[`webservice` chart documentation](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html).
Starting with GitLab 13.0, Puma is the default web server and Unicorn has been disabled.
In GitLab 14.0, [Unicorn was removed](https://docs.gitlab.com/omnibus/update/gitlab_14_changes.html)
from the Linux package and is no longer supported.
Puma is the default web server and Unicorn is no longer supported.
Puma has a multi-thread architecture that uses less memory than a multi-process
application server like Unicorn. On GitLab.com, we saw a 40% reduction in memory

2
doc/administration/operations/ssh_certificates.md
View File

@ -10,8 +10,6 @@ DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** Self-managed
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/19911) in GitLab 11.2.
The default SSH authentication for GitLab requires users to upload their SSH
public keys before they can use the SSH transport.

2
doc/administration/package_information/supported_os.md
View File

@ -77,8 +77,6 @@ To upgrade both the operating system (OS) and GitLab:
## Packages for ARM64
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-omnibus-builder/-/issues/27) in GitLab 13.4.
GitLab provides arm64/aarch64 packages for some supported operating systems.
You can see if your operating system architecture is supported in the table
above.

8
doc/administration/raketasks/check.md
View File

@ -123,10 +123,10 @@ and these checks verify them against current files.
Integrity checks are supported for the following types of file:
- CI artifacts (introduced in GitLab 10.7.0)
- LFS objects (introduced in GitLab 10.6.0)
- CI artifacts
- LFS objects
- Project-level Secure Files (introduced in GitLab 16.1.0)
- User uploads (introduced in GitLab 10.6.0)
- User uploads
- Linux package installations:
@ -211,8 +211,6 @@ See [LDAP Rake Tasks - LDAP Check](ldap.md#check) for details.
## Verify database values can be decrypted using the current secrets
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/20069) in GitLab 13.1.
This task runs through all possible encrypted values in the
database, verifying that they are decryptable using the current
secrets file (`gitlab-secrets.json`).

3
doc/administration/raketasks/maintenance.md
View File

@ -83,9 +83,6 @@ DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20501) in GitLab 12.6.
> - Moved to GitLab Premium in 13.9.
This command shows information about your [GitLab license](../../administration/license.md) and
how many seats are used. It is only available on GitLab Enterprise
installations: a license cannot be installed into GitLab Community Edition.

10
doc/administration/raketasks/project_import_export.md
View File

@ -16,13 +16,11 @@ You can only import from a [compatible](../../user/project/settings/import_expor
## Import large projects
> - The [Rake task](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/tasks/gitlab/import_export/import.rake) was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20724) in GitLab 12.6, replacing a GitLab.com Ruby script.
The [Rake task](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/tasks/gitlab/import_export/import.rake) is used for importing large GitLab project exports.
This script was introduced in GitLab 12.6 for importing large GitLab project exports.
As part of this task, we also disable direct upload. This avoids uploading a huge archive to GCS, which can cause idle transaction timeouts.
As part of this script, we also disable direct upload. This avoids uploading a huge archive to GCS, which can cause idle transaction timeouts.
We can run this script from the terminal:
We can run this task from the terminal:
Parameters:
@ -45,8 +43,6 @@ gitlab-rake "gitlab:import_export:import[root, group/subgroup, testingprojectimp
## Export large projects
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25598) in GitLab 12.9.
You can use a Rake task to export large project.
Parameters:

2
doc/administration/raketasks/smtp.md
View File

@ -10,8 +10,6 @@ DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** Self-managed
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67802) in GitLab 14.2.
The following are SMTP-related Rake tasks.
## Secrets

3
doc/administration/raketasks/uploads/migrate.md
View File

@ -49,8 +49,7 @@ To migrate all uploads from local storage to object storage, run:
You can optionally track progress and verify that all uploads migrated successfully using the
[PostgreSQL console](https://docs.gitlab.com/omnibus/settings/database.html#connecting-to-the-bundled-postgresql-database):
- `sudo gitlab-rails dbconsole` for Linux package installations running GitLab 14.1 and earlier.
- `sudo gitlab-rails dbconsole --database main` for Linux package installations running GitLab 14.2 and later.
- `sudo gitlab-rails dbconsole --database main` for Linux package installations.
- `sudo -u git -H psql -d gitlabhq_production` for self-compiled installations.
Verify `objectstg` below (where `store=2`) has count of all artifacts:

2
doc/administration/raketasks/uploads/sanitize.md
View File

@ -10,7 +10,7 @@ DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** Self-managed
In GitLab 11.9 and later, EXIF data is automatically stripped from JPG or TIFF image uploads.
EXIF data is automatically stripped from JPG or TIFF image uploads.
EXIF data may contain sensitive information (for example, GPS location), so you
can remove EXIF data from existing images that were uploaded to an earlier version of GitLab.

3
doc/administration/read_only_gitlab.md
View File

@ -11,8 +11,7 @@ DETAILS:
**Offering:** Self-managed
NOTE:
In GitLab 13.9 and later, the recommended method to
place GitLab in a read-only state is to enable
The recommended method to place GitLab in a read-only state is to enable
[maintenance mode](../administration/maintenance_mode/index.md).
In some cases, you might want to place GitLab under a read-only state.

2
doc/administration/redis/replication_and_failover.md
View File

@ -498,8 +498,6 @@ which ideally should not have Redis or Sentinels on it for a HA setup.
### Step 5. Enable Monitoring
> - [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3786) in GitLab 12.0.
If you enable Monitoring, it must be enabled on **all** Redis servers.
1. Make sure to collect [`CONSUL_SERVER_NODES`](../postgresql/replication_and_failover.md#consul-information), which are the IP addresses or DNS records of the Consul server nodes, for the next step. Note they are presented as `Y.Y.Y.Y consul1.gitlab.example.com Z.Z.Z.Z`

6
doc/administration/reference_architectures/10k_users.md
View File

@ -2196,12 +2196,6 @@ There are two ways of specifying object storage configuration in GitLab:
The consolidated form is used in the following examples when available.
NOTE:
When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form)
in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
which was deprecated in 14.9, requires shared storage such as NFS.
Using separate buckets for each data type is the recommended approach for GitLab.
This ensures there are no collisions across the various types of data GitLab stores.
There are plans to [enable the use of a single bucket](https://gitlab.com/gitlab-org/gitlab/-/issues/292958)

3
doc/administration/reference_architectures/2k_users.md
View File

@ -1039,8 +1039,7 @@ There are two ways of specifying object storage configuration in GitLab:
The consolidated form is used in the following examples when available.
NOTE:
When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form)
in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form), you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
which was deprecated in 14.9, requires shared storage such as NFS.

3
doc/administration/reference_architectures/3k_users.md
View File

@ -2161,8 +2161,7 @@ There are two ways of specifying object storage configuration in GitLab:
The consolidated form is used in the following examples when available.
NOTE:
When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form)
in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form), you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
which was deprecated in 14.9, requires shared storage such as NFS.

3
doc/administration/reference_architectures/50k_users.md
View File

@ -2217,8 +2217,7 @@ There are two ways of specifying object storage configuration in GitLab:
The consolidated form is used in the following examples when available.
NOTE:
When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form)
in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form), you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
which was deprecated in 14.9, requires shared storage such as NFS.

3
doc/administration/reference_architectures/5k_users.md
View File

@ -2160,8 +2160,7 @@ There are two ways of specifying object storage configuration in GitLab:
The consolidated form is used in the following examples when available.
NOTE:
When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form)
in GitLab 14.x and earlier, you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
When using the [storage-specific form](../object_storage.md#configure-each-object-type-to-define-its-own-storage-connection-storage-specific-form), you should enable [direct upload mode](../../development/uploads/index.md#direct-upload).
The previous [background upload](../../development/uploads/index.md#direct-upload) mode,
which was deprecated in 14.9, requires shared storage such as NFS.

2
doc/administration/reporting/spamcheck.md
View File

@ -10,8 +10,6 @@ DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** Self-managed
> - [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6259) in GitLab 14.8.
WARNING:
Spamcheck is available to all tiers, but only on instances using GitLab Enterprise Edition (EE). For [licensing reasons](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6259#note_726605397), it is not included in the GitLab Community Edition (CE) package. You can [migrate from CE to EE](../../update/package/convert_to_ee.md).

4
doc/administration/sidekiq/extra_sidekiq_processes.md
View File

@ -19,10 +19,6 @@ The information in this page applies only to Linux package installations.
## Start multiple processes
> - [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4006) in GitLab 12.10, starting multiple processes with Sidekiq cluster.
> - [Sidekiq cluster moved](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/181) to GitLab Free in 12.10.
> - [Sidekiq cluster became default](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4140) in GitLab 13.0.
When starting multiple processes, the number of processes should at most equal
(and **not** exceed) the number of CPU cores you want to dedicate to Sidekiq.
The Sidekiq worker process uses no more than one CPU core.

8
doc/administration/sidekiq/processing_specific_job_classes.md
View File

@ -27,7 +27,6 @@ choose one or the other; there is no particular benefit in combining them.
## Routing rules
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/59604) in GitLab 13.12.
> - [Default routing rule value](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/97908) added in GitLab 15.4.
NOTE:
@ -112,11 +111,6 @@ not a recommendation.
## Queue selectors (deprecated)
> - [Introduced](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/45) in GitLab 12.8.
> - [Sidekiq cluster, including queue selector, moved](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/181) to GitLab Free in 12.10.
> - [Renamed from `experimental_queue_selector` to `queue_selector`](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/147) in GitLab 13.6.
> - [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/390787) in GitLab 15.9.
WARNING:
This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/390787) in GitLab 15.9
and is planned for removal in 17.0. Most instances should have [all processes to listen to all queues](extra_sidekiq_processes.md#start-multiple-processes).
@ -312,8 +306,6 @@ query syntax is employed by both [routing rules](#routing-rules) and
### Available attributes
> - [Introduced](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/261) in GitLab 13.1 (`tags`).
Queue matching query works upon the worker attributes, described in
[Sidekiq style guide](../../development/sidekiq/index.md). We support querying
based on a subset of worker attributes:

64
doc/administration/sidekiq/sidekiq_troubleshooting.md
View File

@ -30,8 +30,7 @@ preventing other threads from continuing.
## Log arguments to Sidekiq jobs
[In GitLab 13.6 and later](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/44853)
some arguments passed to Sidekiq jobs are logged by default.
Some arguments passed to Sidekiq jobs are logged by default.
To avoid logging sensitive information (for instance, password reset tokens),
GitLab logs numeric arguments for all workers, with overrides for some specific
workers where their arguments are not sensitive.
@ -58,8 +57,6 @@ Example:
gitlab_rails['env'] = {"SIDEKIQ_LOG_ARGUMENTS" => "0"}
```
In GitLab 13.5 and earlier, set `SIDEKIQ_LOG_ARGUMENTS` to `1` to start logging arguments passed to Sidekiq.
## Investigating Sidekiq queue backlogs or slow performance
Symptoms of slow Sidekiq performance include problems with merge request status updates,
@ -478,8 +475,6 @@ end
## Canceling running jobs (destructive)
> - Introduced in GitLab 12.3.
This is highly risky operation and use it as last resort.
Doing that might result in data corruption, as the job
is interrupted mid-execution and it is not guaranteed
@ -588,63 +583,6 @@ but if you want to clear the idempotency key immediately, follow the following s
dj.delete!
```
## GitLab 14.0 and later: remove the `sidekiq-cluster` service (Linux package installations)
Linux package instances that were configured to run `sidekiq-cluster` prior to GitLab 14.0
might still have this service running along side `sidekiq` in later releases.
The code to manage `sidekiq-cluster` was removed in GitLab 14.0.
The configuration files remain on disk so the `sidekiq-cluster` process continues
to be started by the GitLab systemd service .
The extra service can be identified as running by:
- `gitlab-ctl status` showing both services:
```plaintext
run: sidekiq: (pid 1386) 445s; run: log: (pid 1385) 445s
run: sidekiq-cluster: (pid 1388) 445s; run: log: (pid 1381) 445s
```
- `ps -ef | grep 'runsv sidekiq'` showing two processes:
```plaintext
root 31047 31045 0 13:54 ? 00:00:00 runsv sidekiq-cluster
root 31054 31045 0 13:54 ? 00:00:00 runsv sidekiq
```
To remove the `sidekiq-cluster` service from servers running GitLab 14.0 and later:
1. Stop GitLab and the systemd service:
```shell
sudo gitlab-ctl stop
sudo systemctl stop gitlab-runsvdir.service
```
1. Remove the `runsv` service definition:
```shell
sudo rm -rf /opt/gitlab/sv/sidekiq-cluster
```
1. Restart GitLab:
```shell
sudo systemctl start gitlab-runsvdir.service
```
1. Check that all services are up, and the `sidekiq-cluster` service is not listed:
```shell
sudo gitlab-ctl status
```
This change might reduce the amount of work Sidekiq can do. Symptoms like delays creating pipelines
indicate that additional Sidekiq processes would be beneficial.
Consider [adding additional Sidekiq processes](extra_sidekiq_processes.md)
to compensate for removing the `sidekiq-cluster` service.
## CPU saturation in Redis caused by Sidekiq BRPOP calls
Sidekiq `BROP` calls can cause CPU usage to increase on Redis.

9
doc/administration/timezone.md
View File

@ -49,16 +49,9 @@ gitlab-ctl restart
## Changing time zone per user
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/57654) in GitLab 11.11, disabled by default behind `user_time_settings` [feature flag](feature_flags.md).
> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/29669) in GitLab 13.9.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/29669) in GitLab 14.1.
Users can set their time zone in their profile. On GitLab.com, the default time zone is UTC.
New users do not have a default time zone in [GitLab 14.4 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/340795). New users must
New users do not have a default time zone. New users must
explicitly set their time zone before it displays on their profile.
In GitLab 14.3 and earlier, users with no configured time zone default to the time zone
[configured at the instance level](#changing-your-time-zone).
For more information, see [Set your time zone](../user/profile/index.md#set-your-time-zone).

6
doc/administration/uploads.md
View File

@ -72,9 +72,9 @@ This configuration relies on valid AWS credentials to be configured already.
### Object Storage Settings
In GitLab 13.2 and later, you should use the
[consolidated object storage settings](object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form).
This section describes the earlier configuration format.
This section describes the storage-specific configuration format.
You should use the
[consolidated object storage settings](object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form) instead.
For self-compiled installations, the following settings are nested under `uploads:` and then `object_store:`. On Linux
package installations, they are prefixed by `uploads_object_store_`.

2
doc/api/admin_sidekiq_queues.md
View File

@ -10,8 +10,6 @@ DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** Self-managed, GitLab Dedicated
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25998) in GitLab 12.9
Delete jobs from a Sidekiq queue that match the given
[metadata](../development/logging.md#logging-context-metadata-through-rails-or-grape-requests).

3
doc/api/audit_events.md
View File

@ -10,7 +10,6 @@ DETAILS:
**Tier:** Premium, Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/121) in GitLab 12.4.
> - [Author Email added to the response body](https://gitlab.com/gitlab-org/gitlab/-/issues/386322) in GitLab 15.9.
## Instance Audit Events
@ -287,8 +286,6 @@ Example response:
## Project Audit Events
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/219238) in GitLab 13.1.
Use this API to retrieve project audit events.
A user with a Maintainer role (or above) can retrieve project audit events of all users.

5
doc/api/personal_access_tokens.md
View File

@ -14,8 +14,6 @@ You can read more about [personal access tokens](../user/profile/personal_access
## List personal access tokens
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/227264) in GitLab 13.3.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/270200) from GitLab Ultimate to GitLab Free in 13.6.
> - `created_after`, `created_before`, `last_used_after`, `last_used_before`, `revoked`, `search` and `state` filters were [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/362248) in GitLab 15.5.
Get all personal access tokens the authenticated user has access to. By default, returns an unfiltered list of:
@ -337,9 +335,6 @@ Revoke a personal access token by either:
### Using a personal access token ID
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216004) in GitLab 13.3.
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/270200) from GitLab Ultimate to GitLab Free in 13.6.
Revoke a personal access token using its ID.
```plaintext

8
doc/api/status_checks.md
View File

@ -10,9 +10,6 @@ DETAILS:
**Tier:** Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3869) in GitLab 14.0, disabled behind the `:ff_external_status_checks` feature flag.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/320783) in GitLab 14.1.
## Get project external status check services
You can request information about a project's external status check services using the following endpoint:
@ -130,10 +127,7 @@ GET /projects/:id/merge_requests/:merge_request_iid/status_checks
## Set status of an external status check
> - Introduced in GitLab 14.9, `passed` status to pass external status checks. Introduced [with a flag](../administration/feature_flags.md) named `status_checks_add_status_field`. Disabled by default.
> - Introduced in GitLab 14.9, `failed` status to fail external status checks. Introduced [with a flag](../administration/feature_flags.md) named `status_checks_add_status_field`. Disabled by default.
> - `pass` status to pass checks is [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/339039) in GitLab 14.9. Replaced with `passed`.
> - Support for `failed` and `passed` [enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/353836) in GitLab 15.0 and feature flag removed.
> - Support for `failed` and `passed` [enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/353836) in GitLab 15.0
> - Support for `pending` in GitLab 16.5 [enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/413723) in GitLab 16.5
For a single merge request, use the API to inform GitLab that a merge request has passed a check by an external service.

27
doc/ci/testing/code_quality_troubleshooting.md
View File

@ -28,21 +28,20 @@ is still used.
## No Code Quality report is displayed in a merge request
This can be due to multiple reasons:
Code Quality reports from the source or target branch may be missing for comparison on the merge request, so no information can be displayed.
- You just added the Code Quality job in your `.gitlab-ci.yml`. The report does not have anything to
compare to yet, so no information can be displayed. It only displays after future merge requests
have something to compare to.
- Your pipeline is not set to run the code quality job on your target branch. If there is no report
generated from the target branch, your merge request branch reports have nothing to compare to. In this
situation you get an error stating `Base pipeline codequality artifact not found`.
- The [`artifacts:expire_in`](../yaml/index.md#artifactsexpire_in) CI/CD setting can cause the Code
Quality artifacts to expire faster than desired.
- The widgets use the pipeline of the latest commit to the target branch. If commits are made to the
default branch that do not run the code quality job, this may cause the merge request widget to
have no base report for comparison.
- If you use the [`REPORT_STDOUT` environment variable](https://gitlab.com/gitlab-org/ci-cd/codequality#environment-variables),
no report file is generated and nothing displays in the merge request.
Missing report on the source branch can be due to:
1. Use of the [`REPORT_STDOUT` environment variable](https://gitlab.com/gitlab-org/ci-cd/codequality#environment-variables), no report file is generated and nothing displays in the merge request.
Missing report on the target branch can be due to:
- Newly added Code Quality job in your `.gitlab-ci.yml`.
- Your pipeline is not set to run the Code Quality job on your target branch.
- Commits are made to the default branch that do not run the Code Quality job.
- The [`artifacts:expire_in`](../yaml/index.md#artifactsexpire_in) CI/CD setting can cause the Code Quality artifacts to expire faster than desired.
Verify the presence of report on the base commit by obtaining the `base_sha` using the [merge request API](../../api/merge_requests.md#get-single-mr) and use the [pipelines API with the `sha` attribute](../../api/pipelines.md#list-project-pipelines) to check if pipelines ran.
## Only a single Code Quality report is displayed, but more are defined

2
doc/development/application_limits.md
View File

@ -139,8 +139,6 @@ end
### Subscription Plans
> - The `opensource` plan was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/346399) in GitLab 14.7.
Self-managed:
- `default`: Everyone.

8
doc/install/aws/index.md
View File

@ -496,7 +496,7 @@ Connect to your GitLab instance via **Bastion Host A** using [SSH Agent Forwardi
#### Disable Let's Encrypt
Because we're adding our SSL certificate at the load balancer, we do not need the GitLab built-in support for Let's Encrypt. Let's Encrypt [is enabled by default](https://docs.gitlab.com/omnibus/settings/ssl/index.html#enable-the-lets-encrypt-integration) when using an `https` domain in GitLab 10.7 and later, so we must explicitly disable it:
Because we're adding our SSL certificate at the load balancer, we do not need the GitLab built-in support for Let's Encrypt. Let's Encrypt [is enabled by default](https://docs.gitlab.com/omnibus/settings/ssl/index.html#enable-the-lets-encrypt-integration) when using an `https` domain, so we must explicitly disable it:
1. Open `/etc/gitlab/gitlab.rb` and disable it:
@ -783,9 +783,6 @@ To back up GitLab:
sudo gitlab-backup create
```
NOTE:
For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
### Restoring GitLab from a backup
To restore GitLab, first review the [restore documentation](../../administration/backup_restore/index.md#restore-gitlab),
@ -804,9 +801,6 @@ released, you can update your GitLab instance:
sudo gitlab-backup create
```
NOTE:
For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
1. Update the repositories and install GitLab:
```shell

9
doc/install/installation.md
View File

@ -129,7 +129,7 @@ you might have to install 1.1 manually.
### Git
From GitLab 13.6, we recommend you use the
You should use the
[Git version provided by Gitaly](https://gitlab.com/gitlab-org/gitaly/-/issues/2729)
that:
@ -144,7 +144,7 @@ that:
1. Clone the Gitaly repository and compile Git. Replace `<X-Y-stable>` with the
stable branch that matches the GitLab version you want to install. For example,
if you want to install GitLab 13.6, use the branch name `13-6-stable`:
if you want to install GitLab 16.7, use the branch name `16-7-stable`:
```shell
git clone https://gitlab.com/gitlab-org/gitaly.git -b <X-Y-stable> /tmp/gitaly
@ -293,7 +293,8 @@ sudo adduser --disabled-login --gecos 'GitLab' git
## 7. Database
NOTE:
In GitLab 12.1 and later, only PostgreSQL is supported. In GitLab 16.0 and later, we [require PostgreSQL 13+](requirements.md#postgresql-requirements).
Only PostgreSQL is supported.
In GitLab 16.0 and later, we [require PostgreSQL 13+](requirements.md#postgresql-requirements).
1. Install the database packages.
@ -339,7 +340,7 @@ In GitLab 12.1 and later, only PostgreSQL is supported. In GitLab 16.0 and later
sudo -u postgres psql -d template1 -c "CREATE EXTENSION IF NOT EXISTS pg_trgm;"
```
1. Create the `btree_gist` extension (required for GitLab 13.1+):
1. Create the `btree_gist` extension:
```shell
sudo -u postgres psql -d template1 -c "CREATE EXTENSION IF NOT EXISTS btree_gist;"

6
doc/install/requirements.md
View File

@ -100,9 +100,6 @@ The following managed PostgreSQL services are known to be incompatible and shoul
|----------------|-------------------------------------------------------|
| 14.4+ | Amazon Aurora (see [14.4.0](../update/versions/gitlab_14_changes.md#1440)) |
NOTE:
Support for [PostgreSQL 9.6 and 10 was removed in GitLab 13.0](https://about.gitlab.com/releases/2020/05/22/gitlab-13-0-released/#postgresql-11-is-now-the-minimum-required-version-to-install-gitlab) so that GitLab can benefit from PostgreSQL 11 improvements, such as partitioning.
#### Additional requirements for GitLab Geo
If you're using [GitLab Geo](../administration/geo/index.md), we strongly recommend running instances installed by using the Linux package or using
@ -303,9 +300,6 @@ are configured so that a **single job** runs in a **single instance** with:
## Supported web browsers
WARNING:
With GitLab 13.0 (May 2020) we have removed official support for Internet Explorer 11.
GitLab supports the following web browsers:
- [Mozilla Firefox](https://www.mozilla.org/en-US/firefox/new/)

18
doc/integration/mattermost/index.md
View File

@ -45,7 +45,7 @@ you need to manually authorize GitLab Mattermost for access to GitLab using the
## Configuring Mattermost
Starting in GitLab 11.0, Mattermost can be configured using the Mattermost System Console. An extensive list of
Mattermost can be configured using the Mattermost System Console. An extensive list of
Mattermost settings and where they can be set is available [in the Mattermost documentation](https://docs.mattermost.com/administration/config-settings.html).
While using the System Console is recommended, you can also configure Mattermost using one of the following options:
@ -358,7 +358,7 @@ For a complete list of upgrade notices and special considerations for older vers
### GitLab Mattermost versions shipped with the Linux package
Below is a list of Mattermost version changes for GitLab 14.0 and later:
Below is a list of Mattermost version changes for GitLab 15.0 and later:
| GitLab version | Mattermost version | Notes |
| :------------- | :----------------- | ---------------------------------------------------------------------------------------- |
@ -383,20 +383,6 @@ Below is a list of Mattermost version changes for GitLab 14.0 and later:
| 15.2 | 7.0 | |
| 15.1 | 6.7 | |
| 15.0 | 6.6 | |
| 14.10 | 6.5 | |
| 14.9 | 6.4 | |
| 14.8 | 6.3 | |
| 14.7 | 6.2 | |
| 14.6 | 6.1 | Updates to 6.1 instead of 6.0. [See upgrade notes](#upgrading-gitlab-mattermost-to-146). |
| 14.4 | 5.39 | |
| 14.3 | 5.38 | |
| 14.2 | 5.37 | |
| 14.1 | 5.36 | |
| 14.0 | 5.35 | |
### Upgrading GitLab Mattermost to 14.6
GitLab 14.6 ships with Mattermost 6.1 including potentially long running database migrations for Mattermost 6.0. For information about upgrading and for ways to reduce the downtime caused by those migrations, read the [Important Upgrade Notes](https://docs.mattermost.com/administration/important-upgrade-notes.html) for both versions. If you need to perform any manual migrations, [connect to the bundled PostgreSQL database](#connecting-to-the-bundled-postgresql-database).
NOTE:
The Mattermost upgrade notes refer to different impacts when used with a PostgreSQL versus a MySQL database. The GitLab Mattermost included with the Linux package uses a PostgreSQL database.

19
doc/raketasks/cleanup.md
View File

@ -14,8 +14,6 @@ GitLab provides Rake tasks for cleaning up GitLab instances.
## Remove unreferenced LFS files
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/36628) in GitLab 12.10.
WARNING:
Do not run this within 12 hours of a GitLab upgrade. This is to ensure that all background migrations
have finished, which otherwise may lead to data loss.
@ -55,8 +53,6 @@ later (once a day). If you need to garbage collect them immediately, run
### Remove unreferenced LFS files immediately
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/36628) in GitLab 12.10.
Unreferenced LFS files are removed on a daily basis but you can remove them immediately if
you need to. For example:
@ -81,8 +77,6 @@ Clean up project upload files if they don't exist in GitLab database.
### Clean up project upload files from file system
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20863) in GitLab 11.2.
Clean up local project upload files if they don't exist in GitLab database. The
task attempts to fix the file if it can find its project, otherwise it moves the
file to a lost and found directory.
@ -119,8 +113,6 @@ If using object storage, run the [All-in-one Rake task](../administration/raketa
### Clean up project upload files from object storage
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20918) in GitLab 11.2.
Move object store upload files to a lost and found directory if they don't exist in GitLab database.
```shell
@ -152,19 +144,10 @@ I, [2018-08-02T10:26:47.764356 #45087] INFO -- : Moved to lost and found: @hash
## Remove orphan artifact files
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/29681) in GitLab 12.1.
> - [`ionice` support fixed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28023) in GitLab 12.10.
NOTE:
These commands don't work for artifacts stored on
[object storage](../administration/object_storage.md).
WARNING:
Prior to GitLab 14.9, this task incorrectly deletes [test coverage-related artifacts](../ci/testing/test_coverage_visualization.md).
[The bug fix](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/81022) was
also back-ported to 14.6.6, 14.7.5, and 14.8.3. Upgrade to a release with the bug
fix to avoid data loss.
When you notice there are more job artifacts files and/or directories on disk than there
should be, you can run:
@ -210,8 +193,6 @@ level with `NICENESS`. Below are the valid levels, but consult
## Remove expired ActiveSession lookup keys
> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30668) in GitLab 12.2.
```shell
# omnibus-gitlab
sudo gitlab-rake gitlab:cleanup:sessions:active_sessions_lookup_keys

8
doc/update/index.md
View File

@ -203,8 +203,6 @@ When upgrading:
1. Find where your version sits in the upgrade path:
- GitLab 14: [`14.0.12`](versions/gitlab_14_changes.md#1400) > [`14.3.6`](versions/gitlab_14_changes.md#1430) >
[`14.9.5`](versions/gitlab_14_changes.md#1490) > [`14.10.5`](versions/gitlab_14_changes.md#14100).
- GitLab 15: [`15.0.5`](versions/gitlab_15_changes.md#1500) > [`15.1.6`](versions/gitlab_15_changes.md#1510) (for
GitLab instances with multiple web nodes) > [`15.4.6`](versions/gitlab_15_changes.md#1540) >
[`15.11.13`](versions/gitlab_15_changes.md#15110).
@ -222,7 +220,7 @@ When upgrading:
NOTE:
When not explicitly specified, upgrade GitLab to the latest available patch
release of the `major`.`minor` release rather than the first patch release, for example `13.8.8` instead of `13.8.0`.
release of the `major`.`minor` release rather than the first patch release, for example `16.8.7` instead of `16.8.0`.
This includes `major`.`minor` versions you must stop at on the upgrade path as there may
be fixes for issues relating to the upgrade process.
Specifically around a [major version](#upgrading-to-a-new-major-version),
@ -317,10 +315,6 @@ Before upgrading to GitLab 16, see [GitLab 16 changes](versions/gitlab_16_change
Before upgrading to GitLab 15, see [GitLab 15 changes](versions/gitlab_15_changes.md).
### GitLab 14
Before upgrading to GitLab 14, see [GitLab 14 changes](versions/gitlab_14_changes.md).
## Miscellaneous
- [Managing PostgreSQL extensions](../install/postgresql_extensions.md)

8
doc/update/package/downgrade.md
View File

@ -20,7 +20,7 @@ downgrading to. Ideally, you should have a
on hand.
The example below demonstrates the downgrade procedure when downgrading between minor
and patch versions (for example, from 13.0.6 to 13.0.5).
and patch versions (for example, from 15.0.6 to 15.0.5).
When downgrading between major versions, take into account the
[specific version changes](index.md#version-specific-changes) that occurred when you upgraded
@ -65,16 +65,16 @@ Steps:
sudo yum --showduplicates list gitlab-ee
```
1. Downgrade GitLab to the desired version (for example, to GitLab 13.0.5):
1. Downgrade GitLab to the desired version (for example, to GitLab 15.0.5):
```shell
# (Replace with gitlab-ce if you have GitLab FOSS installed)
# Ubuntu
sudo apt install gitlab-ee=13.0.5-ee.0
sudo apt install gitlab-ee=15.0.5-ee.0
# CentOS:
sudo yum install gitlab-ee-13.0.5-ee.0.el8
sudo yum install gitlab-ee-15.0.5-ee.0.el8
```
1. Reconfigure GitLab:

2
doc/update/package/index.md
View File

@ -43,9 +43,9 @@ GitLab package.
Upgrading versions might need some manual intervention. For more information,
check the version your are upgrading to:
- [GitLab 17](../versions/gitlab_17_changes.md)
- [GitLab 16](../versions/gitlab_16_changes.md)
- [GitLab 15](../versions/gitlab_15_changes.md)
- [GitLab 14](../versions/gitlab_14_changes.md)
### Earlier GitLab versions

8
doc/update/package/package_troubleshooting.md
View File

@ -76,18 +76,10 @@ To fix this issue:
1. Start a database console:
In GitLab 14.2 and later:
```shell
sudo gitlab-rails dbconsole --database main
```
In GitLab 14.1 and earlier:
```shell
sudo gitlab-rails dbconsole
```
1. Manually add the missing `commit_message_negative_regex` column:
```sql

10
doc/update/upgrading_from_source.md
View File

@ -111,9 +111,7 @@ rm go1.20.8.linux-amd64.tar.gz
To check you are running the minimum required Git version, see
[Git versions](../install/installation.md#software-requirements).
From GitLab 13.6, you should use the
[Git version provided by Gitaly](https://gitlab.com/gitlab-org/gitaly/-/issues/2729)
that:
Use the [Git version provided by Gitaly](https://gitlab.com/gitlab-org/gitaly/-/issues/2729) that:
- Is always at the version required by GitLab.
- May contain custom patches required for proper operation.
@ -131,7 +129,7 @@ sudo make git GIT_PREFIX=/usr/local
```
Replace `<X-Y-stable>` with the stable branch that matches the GitLab version you want to
install. For example, if you want to install GitLab 13.6, use the branch name `13-6-stable`.
install. For example, if you want to install GitLab 16.7, use the branch name `16-7-stable`.
Remember to set `git -> bin_path` to `/usr/local/bin/git` in `config/gitlab.yml`.
@ -406,8 +404,8 @@ steps that apply to self-compiled installations.
To revert to a previous version, you must follow the upgrading guides
for the previous version.
For example, if you have upgraded to GitLab 12.6 and want to revert back to
12.5, follow the guides for upgrading from 12.4 to 12.5. You can
For example, if you have upgraded to GitLab 16.6 and want to revert back to
16.5, follow the guides for upgrading from 16.4 to 16.5. You can
use the version dropdown list at the top of the page to select the right version.
When reverting, you should **not** follow the database migration guides, as the

3
doc/update/versions/gitlab_15_changes.md
View File

@ -923,8 +923,7 @@ DETAILS:
Gitaly. The previous implementation in GitLab Shell was removed in GitLab 15.0. With this change, global server hooks are stored only inside a subdirectory named after the
hook type. Global server hooks can no longer be a single hook file in the root of the custom hooks directory. For example, you must use `<custom_hooks_dir>/<hook_name>.d/*` rather
than `<custom_hooks_dir>/<hook_name>`.
- Use `gitaly['custom_hooks_dir']` in `gitlab.rb` ([introduced in 14.3](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4208))
for Omnibus GitLab. This replaces `gitlab_shell['custom_hooks_dir']`.
- Use `gitaly['custom_hooks_dir']` in `gitlab.rb` for Omnibus GitLab. This replaces `gitlab_shell['custom_hooks_dir']`.
- PostgreSQL 13.6 is being shipped as the default version for fresh installs and
12.10 for upgrades. You can manually upgrade to PostgreSQL 13.6 following the
[upgrade docs](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server) with:

3
doc/user/application_security/dependency_scanning/index.md
View File

@ -275,7 +275,7 @@ The following languages and dependency managers are supported:
<li>
<a id="notes-regarding-supported-languages-and-package-managers-6"></a>
<p>
Support for sbt 1.0.x was <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/415835">deprecated</a> in GitLab 16.8.
Support for sbt 1.0.x was <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/415835">deprecated</a> in GitLab 16.8 and <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/436985">removed</a> in GitLab 17.0.
</p>
</li>
<li>
@ -488,7 +488,6 @@ To support the following package managers, the GitLab analyzers proceed in two s
<td>sbt</td>
<td><a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/v4.9.0/build/gemnasium-maven/debian/config/.tool-versions#L4">1.6.2</a></td>
<td>
<a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/v4.9.0/spec/gemnasium-maven_image_spec.rb#L726-730">1.0.4</a>,
<a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/v4.9.0/spec/gemnasium-maven_image_spec.rb#L732-736">1.1.6</a>,
<a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/v4.9.0/spec/gemnasium-maven_image_spec.rb#L738-742">1.2.8</a>,
<a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/v4.9.0/spec/gemnasium-maven_image_spec.rb#L662-666">1.3.12</a>,

5
doc/user/group/compliance_frameworks.md
View File

@ -10,9 +10,6 @@ DETAILS:
**Tier:** Premium, Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/276221) in GitLab 13.9.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/287779) in GitLab 13.12.
You can create a compliance framework that is a label to identify that your project has certain compliance
requirements or needs additional oversight. The label can optionally enforce
[compliance pipeline configuration](compliance_pipelines.md) to the projects on which it is applied.
@ -76,8 +73,6 @@ To assign a compliance framework to a project:
### GraphQL API
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/333249) in GitLab 14.2.
You can use the [GraphQL API](../../api/graphql/reference/index.md#mutationprojectsetcomplianceframework) to add a
compliance framework to a project.

22
doc/user/group/compliance_pipelines.md
View File

@ -10,10 +10,6 @@ DETAILS:
**Tier:** Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3156) in GitLab 13.9, disabled behind `ff_evaluate_group_level_compliance_pipeline` [feature flag](../../administration/feature_flags.md).
> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/300324) in GitLab 13.11.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/331231) in GitLab 14.2.
Group owners can configure a compliance pipeline in a project separate to other projects. By default, the compliance
pipeline configuration (for example, `.compliance-gitlab-ci.yml`) is run instead of the pipeline configuration (for example, `.gitlab-ci.yml`) of labeled
projects.
@ -271,24 +267,6 @@ cannot change them:
This ensures that your job uses the settings you intend and that they are not overridden by
project-level pipelines.
## Avoid parent and child pipelines in GitLab 14.7 and earlier
NOTE:
This advice does not apply to GitLab 14.8 and later because [a fix](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/78878) added
compatibility for combining compliance pipelines, and parent and child pipelines.
Compliance pipelines start on the run of _every_ pipeline in a labeled project. This means that if a pipeline in the labeled project
triggers a child pipeline, the compliance pipeline runs first. This can trigger the parent pipeline, instead of the child pipeline.
Therefore, in projects with compliance frameworks, you should replace
[parent-child pipelines](../../ci/pipelines/downstream_pipelines.md#parent-child-pipelines) with the following:
- Direct [`include`](../../ci/yaml/index.md#include) statements that provide the parent pipeline with child pipeline configuration.
- Child pipelines placed in another project that are run using the [trigger API](../../ci/triggers/index.md) rather than the parent-child
pipeline feature.
This alternative ensures the compliance pipeline does not re-start the parent pipeline.
## Troubleshooting
### Compliance jobs are overwritten by target repository

4
doc/user/project/merge_requests/csv_export.md
View File

@ -48,7 +48,3 @@ The following table shows the attributes in the CSV file.
| Milestone ID | ID of the merge request milestone |
| Created At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` |
| Updated At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` |
In GitLab 14.7 and earlier, the first two columns were `MR ID` and `URL`,
which [caused an issue](https://gitlab.com/gitlab-org/gitlab/-/issues/34769)
when importing back into GitLab.

4
doc/user/project/merge_requests/status_checks.md
View File

@ -10,9 +10,6 @@ DETAILS:
**Tier:** Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3869) in GitLab 14.0, disabled behind the `:ff_external_status_checks` feature flag.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/320783) in GitLab 14.1.
> - `failed` status [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/329636) in GitLab 14.9.
> - `pending` status [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/413723) in GitLab 16.5
> - Timeout interval of two minutes for `pending` status checks [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/388725) in GitLab 16.6.
@ -157,7 +154,6 @@ the status check and it **is not** recoverable.
## Status checks widget
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/327634) in GitLab 14.1.
> - UI [updated](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91504) in GitLab 15.2.
> - Ability to retry failed external status checks [added](https://gitlab.com/gitlab-org/gitlab/-/issues/383200) in GitLab 15.8.
> - Widget [updated](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111763) to poll for updates when there are pending status checks in GitLab 15.11.

8
doc/user/project/releases/release_evidence.md
View File

@ -10,8 +10,6 @@ DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26019) in GitLab 12.6.
Each time a release is created, GitLab takes a snapshot of data that's related to it.
This data is saved in a JSON file and called *release evidence*. The feature
includes test artifacts and linked milestones to facilitate
@ -93,8 +91,6 @@ DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed, GitLab Dedicated
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/199065) in GitLab 12.10.
When a release is created, release evidence is automatically collected. To initiate evidence collection any other time, use an [API call](../../../api/releases/index.md#collect-release-evidence). You can collect release evidence multiple times for one release.
Evidence collection snapshots are visible on the Releases page, along with the timestamp the evidence was collected.
@ -105,8 +101,6 @@ DETAILS:
**Tier:** Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32773) in GitLab 13.2.
When you create a release, if [job artifacts](../../../ci/yaml/index.md#artifactsreports) are included in the last pipeline that ran, they are automatically included in the release as release evidence.
Although job artifacts usually expire, artifacts included in release evidence do not expire.
@ -139,8 +133,6 @@ keyword. For more information, see [issue 222351](https://gitlab.com/gitlab-org/
## Schedule release evidence collection
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/23697) in GitLab 12.8.
In the API:
- If you specify a future `released_at` date, the release becomes an **Upcoming release**