From 341c61cf4c8b6f1cccb30c8cca649871f13c997c Mon Sep 17 00:00:00 2001 From: Marcel Amirault <mamirault@gitlab.com> Date: Mon, 2 Sep 2024 19:23:44 +0900 Subject: [PATCH] Fix spacing of nesting list items Fix nesting of list items in admin docs --- doc/administration/auth/atlassian.md | 6 +-- doc/administration/auth/oidc.md | 2 +- .../backup_restore/backup_archive_process.md | 4 +- .../dedicated/configure_instance.md | 30 +++++------ .../dedicated/hosted_runners.md | 10 ++-- doc/administration/gitaly/praefect.md | 4 +- doc/administration/gitaly/recovery.md | 2 +- doc/administration/object_storage.md | 54 +++++++++---------- .../operations/filesystem_benchmarking.md | 6 +-- .../postgresql/database_load_balancing.md | 26 ++++----- doc/administration/postgresql/external.md | 6 +-- .../postgresql/multiple_databases.md | 18 +++---- .../postgresql/replication_and_failover.md | 6 +-- doc/administration/raketasks/check.md | 54 +++++++++---------- doc/administration/settings/scim_setup.md | 4 +- .../sidekiq/sidekiq_troubleshooting.md | 20 +++---- doc/administration/whats-new.md | 6 +-- 17 files changed, 129 insertions(+), 129 deletions(-) diff --git a/doc/administration/auth/atlassian.md b/doc/administration/auth/atlassian.md index 7c3309346075f..9da8c9c3c2fa7 100644 --- a/doc/administration/auth/atlassian.md +++ b/doc/administration/auth/atlassian.md @@ -24,9 +24,9 @@ To enable the Atlassian OmniAuth provider for passwordless authentication you mu 1. Select **+ Add** in the left sidebar under **APIS AND FEATURES**. 1. Select **Add** for **Jira platform REST API** and then **Configure**. 1. Select **Add** next to the following scopes: - - **View Jira issue data** - - **View user profiles** - - **Create and manage issues** + - **View Jira issue data** + - **View user profiles** + - **Create and manage issues** ## GitLab configuration diff --git a/doc/administration/auth/oidc.md b/doc/administration/auth/oidc.md index 8cd8d4c1a3e54..97bcf732904c8 100644 --- a/doc/administration/auth/oidc.md +++ b/doc/administration/auth/oidc.md @@ -1112,7 +1112,7 @@ response to assign users as administrator based on group membership, configure G - Where to look for the groups in the OIDC response, using the `groups_attribute` setting. - Which group memberships grant the user administrator access, using the - `admin_groups` setting. + `admin_groups` setting. ::Tabs diff --git a/doc/administration/backup_restore/backup_archive_process.md b/doc/administration/backup_restore/backup_archive_process.md index 090515f5d9ba9..f6ec437933440 100644 --- a/doc/administration/backup_restore/backup_archive_process.md +++ b/doc/administration/backup_restore/backup_archive_process.md @@ -35,8 +35,8 @@ To back up Git repositories, the `repositories` sub-task: 1. Informs `gitaly-backup` which repositories to back up. 1. Runs `gitaly-backup` to: - - Call a series of Remote Procedure Calls (RPCs) on Gitaly. - - Collect the backup data for each repository. + - Call a series of Remote Procedure Calls (RPCs) on Gitaly. + - Collect the backup data for each repository. 1. Streams the collected data into a directory structure in the [backup staging directory](#backup-staging-directory). diff --git a/doc/administration/dedicated/configure_instance.md b/doc/administration/dedicated/configure_instance.md index d8915c95ddf6a..b60109c029280 100644 --- a/doc/administration/dedicated/configure_instance.md +++ b/doc/administration/dedicated/configure_instance.md @@ -169,8 +169,8 @@ To enable an Outbound Private Link: will be available to GitLab Dedicated. Provide the associated `Service Endpoint Name` on a new [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650). 1. Make sure you have configured a Network Load Balancer (NLB) for the endpoint service in the AZs to which your Dedicated instance was deployed. If you did not specify these during onboarding to Dedicated, you must either: - - Submit a [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650) to request the AZ IDs required to enable the connection and ensure the NLB is enabled in those AZs. - - Ensure the NLB is enabled in every AZ in the region. + - Submit a [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650) to request the AZ IDs required to enable the connection and ensure the NLB is enabled in those AZs. + - Ensure the NLB is enabled in every AZ in the region. 1. In your [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650), GitLab will provide you with the ARN of an IAM role that will be initiating the connection to your endpoint service. You must ensure this ARN is included, or otherwise covered by other entries, in the list of "Allowed Principals" on the Endpoint Service, as described by the [AWS documentation](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html#add-remove-permissions). @@ -275,25 +275,25 @@ To activate SAML for your GitLab Dedicated instance: 1. Expand **SAML Config**. 1. Turn on the **Enable** toggle. 1. Complete the required fields: - - SAML label - - IdP cert fingerprint - - IdP SSO target URL + - SAML label + - IdP cert fingerprint + - IdP SSO target URL 1. Optional. To configure users based on SAML group membership, complete the following fields: - - SAML group attribute - - Admin groups - - Auditor groups - - External groups - - Required groups + - SAML group attribute + - Admin groups + - Auditor groups + - External groups + - Required groups 1. Optional. To configure SAML request signing, complete the following fields: - - Name identifier format - - Attribute statements - - Security + - Name identifier format + - Attribute statements + - Security 1. Select **Save**. 1. Scroll up to the top of the page and select whether to apply the changes immediately or during the next maintenance window. 1. Optional. To use group sync, [configure the SAML group links](../../user/group/saml_sso/group_sync.md#configure-saml-group-links). 1. To verify the SAML configuration is successful: - - Check that the SSO button description is displayed on your instance's sign-in page. - - Go to the metadata URL of your instance (`https://INSTANCE-URL/users/auth/saml/metadata`). This page can be used to simplify much of the configuration of the identity provider, and manually validate the settings. + - Check that the SSO button description is displayed on your instance's sign-in page. + - Go to the metadata URL of your instance (`https://INSTANCE-URL/users/auth/saml/metadata`). This page can be used to simplify much of the configuration of the identity provider, and manually validate the settings. #### Activate SAML with a Support Request diff --git a/doc/administration/dedicated/hosted_runners.md b/doc/administration/dedicated/hosted_runners.md index d212e0dd56838..ede13320dbad5 100644 --- a/doc/administration/dedicated/hosted_runners.md +++ b/doc/administration/dedicated/hosted_runners.md @@ -176,11 +176,11 @@ To migrate your jobs to use hosted runners: 1. Use the small Linux x86-64 runner for untagged jobs. 1. Add the appropriate tags to your job configurations in the `.gitlab-ci.yml` file: - ```yaml - job_name: - tags: - - linux-medium-amd64 # Use the medium-sized Linux runner - ``` + ```yaml + job_name: + tags: + - linux-medium-amd64 # Use the medium-sized Linux runner + ``` 1. [Modify the tags](#configure-hosted-runners-in-gitlab) to match your existing job configurations. diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md index 68dcd6d6d66ba..3f31ade26b947 100644 --- a/doc/administration/gitaly/praefect.md +++ b/doc/administration/gitaly/praefect.md @@ -1484,8 +1484,8 @@ sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefec - `-virtual-storage` is the virtual storage the repository is located in. - `-repository` is the repository's relative path in the storage. - `-replication-factor` is the desired replication factor of the repository. The minimum value is - `1`, as the primary needs a copy of the repository. The maximum replication factor is the number of - storages in the virtual storage. + `1`, as the primary needs a copy of the repository. The maximum replication factor is the number of + storages in the virtual storage. On success, the assigned host storages are printed. For example: diff --git a/doc/administration/gitaly/recovery.md b/doc/administration/gitaly/recovery.md index 5a4cd6f58150a..7eeab92827af1 100644 --- a/doc/administration/gitaly/recovery.md +++ b/doc/administration/gitaly/recovery.md @@ -232,7 +232,7 @@ When accepting data loss, Praefect: 1. Marks the chosen copy of the repository as the latest version. 1. Replicates the copy to the other assigned Gitaly nodes. - This process overwrites any other copy of the repository so care must be taken. + This process overwrites any other copy of the repository so care must be taken. ## Data recovery diff --git a/doc/administration/object_storage.md b/doc/administration/object_storage.md index 6590a4b0335cb..25350a637afd3 100644 --- a/doc/administration/object_storage.md +++ b/doc/administration/object_storage.md @@ -1004,36 +1004,36 @@ In some situations, it may be helpful to test object storage settings using the 1. Start a [Rails console](operations/rails_console.md). 1. Set up the object storage connection, using the same parameters you set up in `/etc/gitlab/gitlab.rb`, in the following example format: -Example connection using access keys: + Example connection using access keys: - ```ruby - connection = Fog::Storage.new( - { - provider: 'AWS', - region: `eu-central-1`, - aws_access_key_id: '<AWS_ACCESS_KEY_ID>', - aws_secret_access_key: '<AWS_SECRET_ACCESS_KEY>' - } - ) - ``` + ```ruby + connection = Fog::Storage.new( + { + provider: 'AWS', + region: `eu-central-1`, + aws_access_key_id: '<AWS_ACCESS_KEY_ID>', + aws_secret_access_key: '<AWS_SECRET_ACCESS_KEY>' + } + ) + ``` -Example connection using AWS IAM Profiles: + Example connection using AWS IAM Profiles: - ```ruby - connection = Fog::Storage.new( - { - provider: 'AWS', - use_iam_profile: true, - region: 'us-east-1' - } - ) - ``` + ```ruby + connection = Fog::Storage.new( + { + provider: 'AWS', + use_iam_profile: true, + region: 'us-east-1' + } + ) + ``` 1. Specify the bucket name to test against, write, and finally read a test file. - ```ruby - dir = connection.directories.new(key: '<bucket-name-here>') - f = dir.files.create(key: 'test.txt', body: 'test') - pp f - pp dir.files.head('test.txt') - ``` + ```ruby + dir = connection.directories.new(key: '<bucket-name-here>') + f = dir.files.create(key: 'test.txt', body: 'test') + pp f + pp dir.files.head('test.txt') + ``` diff --git a/doc/administration/operations/filesystem_benchmarking.md b/doc/administration/operations/filesystem_benchmarking.md index 16f20efe3c1e6..865302577c630 100644 --- a/doc/administration/operations/filesystem_benchmarking.md +++ b/doc/administration/operations/filesystem_benchmarking.md @@ -107,9 +107,9 @@ executed, and then reads the same 1,000 files. 1. Remove the test files: - ```shell - cd ../; rm -rf test - ``` + ```shell + cd ../; rm -rf test + ``` The output of the `time for ...` commands resemble the following. The important metric is the `real` time. diff --git a/doc/administration/postgresql/database_load_balancing.md b/doc/administration/postgresql/database_load_balancing.md index 17dec0e4a85ee..ba508578880ad 100644 --- a/doc/administration/postgresql/database_load_balancing.md +++ b/doc/administration/postgresql/database_load_balancing.md @@ -116,17 +116,17 @@ record. For example: 1. On each GitLab Rails / Sidekiq node, edit `/etc/gitlab/gitlab.rb` and add the following: - ```ruby - gitlab_rails['db_load_balancing'] = { 'discover' => { - 'nameserver' => 'localhost' - 'record' => 'postgresql-ha.service.consul' - 'record_type' => 'A' - 'port' => '8600' - 'interval' => '60' - 'disconnect_timeout' => '120' - } - } - ``` + ```ruby + gitlab_rails['db_load_balancing'] = { 'discover' => { + 'nameserver' => 'localhost' + 'record' => 'postgresql-ha.service.consul' + 'record_type' => 'A' + 'port' => '8600' + 'interval' => '60' + 'disconnect_timeout' => '120' + } + } + ``` 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect. @@ -134,12 +134,12 @@ record. For example: |----------------------|---------------------------------------------------------------------------------------------------|-----------| | `nameserver` | The nameserver to use for looking up the DNS record. | localhost | | `record` | The record to look up. This option is required for service discovery to work. | | -| `record_type` | Optional record type to look up. Can be either `A` or `SRV`. | `A` | +| `record_type` | Optional record type to look up. Can be either `A` or `SRV`. | `A` | | `port` | The port of the nameserver. | 8600 | | `interval` | The minimum time in seconds between checking the DNS record. | 60 | | `disconnect_timeout` | The time in seconds after which an old connection is closed, after the list of hosts was updated. | 120 | | `use_tcp` | Lookup DNS resources using TCP instead of UDP | false | -| `max_replica_pools` | The maximum number of replicas each Rails process connects to. This is useful if you run a lot of Postgres replicas and a lot of Rails processes because without this limit every Rails process connects to every replica by default. The default behavior is unlimited if not set. | nil | +| `max_replica_pools` | The maximum number of replicas each Rails process connects to. This is useful if you run a lot of Postgres replicas and a lot of Rails processes because without this limit every Rails process connects to every replica by default. The default behavior is unlimited if not set. | nil | If `record_type` is set to `SRV`, then GitLab continues to use round-robin algorithm and ignores the `weight` and `priority` in the record. Since `SRV` records usually diff --git a/doc/administration/postgresql/external.md b/doc/administration/postgresql/external.md index ff6ba1c6f5f56..5735f2dbb8cbe 100644 --- a/doc/administration/postgresql/external.md +++ b/doc/administration/postgresql/external.md @@ -57,9 +57,9 @@ If you use a cloud-managed service, or provide your own PostgreSQL instance: 1. Restart PostgreSQL to enable the TCP port: - ```shell - sudo gitlab-ctl restart - ``` + ```shell + sudo gitlab-ctl restart + ``` ## Troubleshooting diff --git a/doc/administration/postgresql/multiple_databases.md b/doc/administration/postgresql/multiple_databases.md index 06a239738d5fd..b1ff4b086f932 100644 --- a/doc/administration/postgresql/multiple_databases.md +++ b/doc/administration/postgresql/multiple_databases.md @@ -56,17 +56,17 @@ If something unexpected happens during the migration, it is safe to start over. 1. Verify available disk space: - - The database node that will store the `gitlabhq_production_ci` database needs enough space to store a copy of the existing database: we _duplicate_ `gitlabhq_production`. Run the following SQL query to find out how much space is needed. Add 25%, to ensure you will not run out of disk space. + - The database node that will store the `gitlabhq_production_ci` database needs enough space to store a copy of the existing database: we _duplicate_ `gitlabhq_production`. Run the following SQL query to find out how much space is needed. Add 25%, to ensure you will not run out of disk space. - ```shell - sudo gitlab-psql -c "SELECT pg_size_pretty( pg_database_size('gitlabhq_production') );" - ``` + ```shell + sudo gitlab-psql -c "SELECT pg_size_pretty( pg_database_size('gitlabhq_production') );" + ``` - - During the process, a dump of the `gitlabhq_production` database needs to be temporarily stored on the filesystem of the node that will run the migration. Execute the following SQL statement to find out how much local disk space will be used. Add 25%, to ensure you will not run out of disk space. + - During the process, a dump of the `gitlabhq_production` database needs to be temporarily stored on the filesystem of the node that will run the migration. Execute the following SQL statement to find out how much local disk space will be used. Add 25%, to ensure you will not run out of disk space. - ```shell - sudo gitlab-psql -c "select sum(pg_table_size(concat(table_schema,'.',table_name))) from information_schema.tables where table_catalog = 'gitlabhq_production' and table_type = 'BASE TABLE'" - ``` + ```shell + sudo gitlab-psql -c "select sum(pg_table_size(concat(table_schema,'.',table_name))) from information_schema.tables where table_catalog = 'gitlabhq_production' and table_type = 'BASE TABLE'" + ``` 1. Plan for downtime. The downtime is dependent on the size of the `gitlabhq_production` database. @@ -91,7 +91,7 @@ This process includes downtime. Running the migration script will stop the GitLa 1. Edit `/etc/gitlab/gitlab.rb` and save the changes. Do **not** run the reconfigure command, the migration script will run that for you. - ```ruby + ```ruby gitlab_rails['env'] = { 'GITLAB_ALLOW_SEPARATE_CI_DATABASE' => 'true' } gitlab_rails['databases']['ci']['enable'] = true gitlab_rails['databases']['ci']['db_database'] = 'gitlabhq_production_ci' diff --git a/doc/administration/postgresql/replication_and_failover.md b/doc/administration/postgresql/replication_and_failover.md index 8246c3b8bc9d6..33a08be0f8265 100644 --- a/doc/administration/postgresql/replication_and_failover.md +++ b/doc/administration/postgresql/replication_and_failover.md @@ -165,9 +165,9 @@ When using default setup, minimum configuration requires: - `CONSUL_DATABASE_PASSWORD`. Password for the database user. - `CONSUL_PASSWORD_HASH`. This is a hash generated out of Consul username/password pair. It can be generated with: - ```shell - sudo gitlab-ctl pg-password-md5 CONSUL_USERNAME - ``` + ```shell + sudo gitlab-ctl pg-password-md5 CONSUL_USERNAME + ``` - `CONSUL_SERVER_NODES`. The IP addresses or DNS records of the Consul server nodes. diff --git a/doc/administration/raketasks/check.md b/doc/administration/raketasks/check.md index 06f7e43fdf2f5..282b93ee54cd2 100644 --- a/doc/administration/raketasks/check.md +++ b/doc/administration/raketasks/check.md @@ -302,36 +302,36 @@ To reset broken tokens: 1. Identify the broken tokens. For example `runners_token`. 1. To reset broken tokens, run `gitlab:doctor:reset_encrypted_tokens` with `VERBOSE=true MODEL_NAMES=Model1,Model2 TOKEN_NAMES=broken_token1,broken_token2`. For example: - ```shell - VERBOSE=true MODEL_NAMES=Project,Group TOKEN_NAMES=runners_token bundle exec rake gitlab:doctor:reset_encrypted_tokens - ``` - - You will see every action this task would try to perform: - - ```plain - I, [2023-09-26T16:20:23.230942 #88920] INFO -- : Resetting runners_token on Project, Group if they can not be read - I, [2023-09-26T16:20:23.230975 #88920] INFO -- : Executing in DRY RUN mode, no records will actually be updated - D, [2023-09-26T16:20:30.151585 #88920] DEBUG -- : > Fix Project[1].runners_token - I, [2023-09-26T16:20:30.151617 #88920] INFO -- : Checked 1/9 Projects - D, [2023-09-26T16:20:30.151873 #88920] DEBUG -- : > Fix Project[3].runners_token - D, [2023-09-26T16:20:30.152975 #88920] DEBUG -- : > Fix Project[10].runners_token - I, [2023-09-26T16:20:30.152992 #88920] INFO -- : Checked 11/29 Projects - I, [2023-09-26T16:20:30.153230 #88920] INFO -- : Checked 21/29 Projects - I, [2023-09-26T16:20:30.153882 #88920] INFO -- : Checked 29 Projects - D, [2023-09-26T16:20:30.195929 #88920] DEBUG -- : > Fix Group[22].runners_token - I, [2023-09-26T16:20:30.196125 #88920] INFO -- : Checked 1/19 Groups - D, [2023-09-26T16:20:30.196192 #88920] DEBUG -- : > Fix Group[25].runners_token - D, [2023-09-26T16:20:30.197557 #88920] DEBUG -- : > Fix Group[82].runners_token - I, [2023-09-26T16:20:30.197581 #88920] INFO -- : Checked 11/19 Groups - I, [2023-09-26T16:20:30.198455 #88920] INFO -- : Checked 19 Groups - I, [2023-09-26T16:20:30.198462 #88920] INFO -- : Done! - ``` + ```shell + VERBOSE=true MODEL_NAMES=Project,Group TOKEN_NAMES=runners_token bundle exec rake gitlab:doctor:reset_encrypted_tokens + ``` + + You will see every action this task would try to perform: + + ```plain + I, [2023-09-26T16:20:23.230942 #88920] INFO -- : Resetting runners_token on Project, Group if they can not be read + I, [2023-09-26T16:20:23.230975 #88920] INFO -- : Executing in DRY RUN mode, no records will actually be updated + D, [2023-09-26T16:20:30.151585 #88920] DEBUG -- : > Fix Project[1].runners_token + I, [2023-09-26T16:20:30.151617 #88920] INFO -- : Checked 1/9 Projects + D, [2023-09-26T16:20:30.151873 #88920] DEBUG -- : > Fix Project[3].runners_token + D, [2023-09-26T16:20:30.152975 #88920] DEBUG -- : > Fix Project[10].runners_token + I, [2023-09-26T16:20:30.152992 #88920] INFO -- : Checked 11/29 Projects + I, [2023-09-26T16:20:30.153230 #88920] INFO -- : Checked 21/29 Projects + I, [2023-09-26T16:20:30.153882 #88920] INFO -- : Checked 29 Projects + D, [2023-09-26T16:20:30.195929 #88920] DEBUG -- : > Fix Group[22].runners_token + I, [2023-09-26T16:20:30.196125 #88920] INFO -- : Checked 1/19 Groups + D, [2023-09-26T16:20:30.196192 #88920] DEBUG -- : > Fix Group[25].runners_token + D, [2023-09-26T16:20:30.197557 #88920] DEBUG -- : > Fix Group[82].runners_token + I, [2023-09-26T16:20:30.197581 #88920] INFO -- : Checked 11/19 Groups + I, [2023-09-26T16:20:30.198455 #88920] INFO -- : Checked 19 Groups + I, [2023-09-26T16:20:30.198462 #88920] INFO -- : Done! + ``` 1. If you are confident that this operation resets the correct tokens, disable dry-run mode and run the operation again: - ```shell - DRY_RUN=false VERBOSE=true MODEL_NAMES=Project,Group TOKEN_NAMES=runners_token bundle exec rake gitlab:doctor:reset_encrypted_tokens - ``` + ```shell + DRY_RUN=false VERBOSE=true MODEL_NAMES=Project,Group TOKEN_NAMES=runners_token bundle exec rake gitlab:doctor:reset_encrypted_tokens + ``` ## Troubleshooting diff --git a/doc/administration/settings/scim_setup.md b/doc/administration/settings/scim_setup.md index a68b3fb98491a..89fe2ed175d47 100644 --- a/doc/administration/settings/scim_setup.md +++ b/doc/administration/settings/scim_setup.md @@ -34,8 +34,8 @@ To configure GitLab SCIM: 1. Select **Settings > General**. 1. Expand the **SCIM Token** section and select **Generate a SCIM token**. 1. For configuration of your identity provider, save the: - - Token from the **Your SCIM token** field. - - URL from the **SCIM API endpoint URL** field. + - Token from the **Your SCIM token** field. + - URL from the **SCIM API endpoint URL** field. ## Configure an identity provider diff --git a/doc/administration/sidekiq/sidekiq_troubleshooting.md b/doc/administration/sidekiq/sidekiq_troubleshooting.md index 87264649f1808..1394202a22d71 100644 --- a/doc/administration/sidekiq/sidekiq_troubleshooting.md +++ b/doc/administration/sidekiq/sidekiq_troubleshooting.md @@ -601,20 +601,20 @@ but if you want to clear the idempotency key immediately, follow the following s 1. Find the worker class and `args` of the job in the Sidekiq logs: - ```plaintext - { ... "class":"Geo::VerificationBatchWorker","args":["container_repository"] ... } - ``` + ```plaintext + { ... "class":"Geo::VerificationBatchWorker","args":["container_repository"] ... } + ``` 1. Start a [Rails console session](../operations/rails_console.md#starting-a-rails-console-session). 1. Run the following snippet: - ```ruby - worker_class = Geo::VerificationBatchWorker - args = ["container_repository"] - dj = Gitlab::SidekiqMiddleware::DuplicateJobs::DuplicateJob.new({ 'class' => worker_class.name, 'args' => args }, worker_class.queue) - dj.send(:idempotency_key) - dj.delete! - ``` + ```ruby + worker_class = Geo::VerificationBatchWorker + args = ["container_repository"] + dj = Gitlab::SidekiqMiddleware::DuplicateJobs::DuplicateJob.new({ 'class' => worker_class.name, 'args' => args }, worker_class.queue) + dj.send(:idempotency_key) + dj.delete! + ``` ## CPU saturation in Redis caused by Sidekiq BRPOP calls diff --git a/doc/administration/whats-new.md b/doc/administration/whats-new.md index 93bd65e33ef13..93e6ac1703aff 100644 --- a/doc/administration/whats-new.md +++ b/doc/administration/whats-new.md @@ -19,9 +19,9 @@ All users can see the feature list, but the entries might differ depending on th - Features only available on GitLab.com are not shown to self-managed installations. - Features only available to self-managed installations are not shown on GitLab.com. - NOTE: - For self-managed installations, the updated **What's new** is included - in the first patch release after a new version, such as `13.10.1`. + NOTE: + For self-managed installations, the updated **What's new** is included + in the first patch release after a new version, such as `13.10.1`. ## Access What's new -- GitLab