Remove redundant `**Note:**` from docs

The notation we use to represent a note is:

```
NOTE: **Note:**
This is a note
```

This is rendered by Nanoc and presented in an alert box in the docs
site. The second `**Note:**` can be redundant, so let's remove it.

doc/.vale/gitlab/AlertBoxNoteTip.yml

@@ -5,7 +5,7 @@
 #
 # For a list of all options, see https://errata-ai.gitbook.io/vale/getting-started/styles
 extends: substitution
-message: "NOTE: and TIP: alert boxes must be of the format 'NOTE: **Note:**' or 'TIP: **Tip:**"
+message: "NOTE: and TIP: alert boxes must be of the format 'NOTE:' or 'TIP: **Tip:**"
 link: https://docs.gitlab.com/ee/development/documentation/styleguide.html#alert-boxes
 level: warning
 nonword: true

doc/administration/audit_events.md

@@ -44,7 +44,7 @@ Impersonation is where an administrator uses credentials to perform an action as
 
 ### Group events **(STARTER)**
 
-NOTE: **Note:**
+NOTE:
 You need Owner [permissions](../user/permissions.md) to view the group Audit Events page.
 
 To view a group's audit events, navigate to **Group > Settings > Audit Events**.
@@ -74,7 +74,7 @@ Group events can also be accessed via the [Group Audit Events API](../api/audit_
 
 ### Project events **(STARTER)**
 
-NOTE: **Note:**
+NOTE:
 You need Maintainer [permissions](../user/permissions.md) or higher to view the project Audit Events page.
 
 To view a project's audit events, navigate to **Project > Settings > Audit Events**.

doc/administration/auth/README.md

@@ -36,5 +36,5 @@ providers:
 - [Smartcard](smartcard.md) **(PREMIUM ONLY)**
 - [Twitter](../../integration/twitter.md)
 
-NOTE: **Note:**
+NOTE:
 UltraAuth has removed their software which supports OmniAuth integration. We have therefore removed all references to UltraAuth integration.

doc/administration/auth/jwt.md

@@ -62,7 +62,7 @@ JWT will provide you with a secret key for you to use.
      }
    ```
 
-   NOTE: **Note:**
+   NOTE:
    For more information on each configuration option refer to
    the [OmniAuth JWT usage documentation](https://github.com/mbleigh/omniauth-jwt#usage).
 

doc/administration/auth/ldap/index.md

@@ -91,7 +91,7 @@ There is a Rake task to check LDAP configuration. After configuring LDAP
 using the documentation below, see [LDAP check Rake task](../../raketasks/check.md#ldap-check)
 for information on the LDAP check Rake task.
 
-NOTE: **Note:**
+NOTE:
 The `encryption` value `simple_tls` corresponds to 'Simple TLS' in the LDAP
 library. `start_tls` corresponds to StartTLS, not to be confused with regular TLS.
 Normally, if you specify `simple_tls` it is on port 636, while `start_tls` (StartTLS)
@@ -553,7 +553,7 @@ administrators. Specify a group CN for `admin_group` and all members of the
 LDAP group will be given administrator privileges. The configuration looks
 like the following.
 
-NOTE: **Note:**
+NOTE:
 Administrators are not synced unless `group_base` is also
 specified alongside `admin_group`. Also, only specify the CN of the admin
 group, as opposed to the full DN.

doc/administration/auth/ldap/ldap-troubleshooting.md

@@ -378,7 +378,7 @@ GitLab syncs the `admin_group`.
 
 #### Sync all groups **(STARTER ONLY)**
 
-NOTE: **Note:**
+NOTE:
 To sync all groups manually when debugging is unnecessary, [use the Rake
 task](../../raketasks/ldap.md#run-a-group-sync) instead.
 
@@ -429,7 +429,7 @@ and more DNs may be added, or existing entries modified, based on additional
 LDAP group lookups. The very last occurrence of this entry should indicate
 exactly which users GitLab believes should be added to the group.
 
-NOTE: **Note:**
+NOTE:
 10 is 'Guest', 20 is 'Reporter', 30 is 'Developer', 40 is 'Maintainer'
 and 50 is 'Owner'.
 

doc/administration/auth/oidc.md

@@ -81,7 +81,7 @@ The OpenID Connect will provide you with a client details and secret for you to
        }
    ```
 
-   NOTE: **Note:**
+   NOTE:
    For more information on each configuration option refer to the [OmniAuth OpenID Connect usage documentation](https://github.com/m0n9oose/omniauth_openid_connect#usage)
    and the [OpenID Connect Core 1.0 specification](https://openid.net/specs/openid-connect-core-1_0.html).
 

doc/administration/auth/okta.md

@@ -158,7 +158,7 @@ You might want to try this out on an incognito browser window.
 
 ## Configuring groups
 
-NOTE: **Note:**
+NOTE:
 Make sure the groups exist and are assigned to the Okta app.
 
 You can take a look of the [SAML documentation](../../integration/saml.md#saml-groups) on configuring groups.

doc/administration/auth/smartcard.md

@@ -60,7 +60,7 @@ Certificate:
 Smartcards with X.509 certificates using SAN extensions can be used to authenticate
 with GitLab.
 
-NOTE: **Note:**
+NOTE:
 This is an experimental feature. Smartcard authentication against local databases may
 change or be removed completely in future releases.
 
@@ -211,7 +211,7 @@ attribute. As a prerequisite, you must use an LDAP server that:
      client_certificate_required_port: 3443
    ```
 
-   NOTE: **Note:**
+   NOTE:
    Assign a value to at least one of the following variables:
    `client_certificate_required_host` or `client_certificate_required_port`.
 

doc/administration/database_load_balancing.md

@@ -173,7 +173,7 @@ queried over UDP. To overcome this issue, you can use TCP for querying by settin
 
 ### Forking
 
-NOTE: **Note:**
+NOTE:
 Starting with GitLab 13.0, Puma is the default web server used in GitLab
 all-in-one package based installations as well as GitLab Helm chart deployments.
 

doc/administration/file_hooks.md

@@ -13,12 +13,12 @@ type: reference
 With custom file hooks, GitLab administrators can introduce custom integrations
 without modifying GitLab's source code.
 
-NOTE: **Note:**
+NOTE:
 Instead of writing and supporting your own file hook you can make changes
 directly to the GitLab source code and contribute back upstream. This way we can
 ensure functionality is preserved across versions and covered by tests.
 
-NOTE: **Note:**
+NOTE:
 File hooks must be configured on the filesystem of the GitLab server. Only GitLab
 server administrators will be able to complete these tasks. Explore
 [system hooks](../system_hooks/system_hooks.md) or [webhooks](../user/project/integrations/webhooks.md) as an option if you do not have filesystem access.

doc/administration/geo/disaster_recovery/background_verification.md

@@ -7,7 +7,7 @@ type: howto
 
 # Automatic background verification **(PREMIUM ONLY)**
 
-NOTE: **Note:**
+NOTE:
 Automatic background verification of repositories and wikis was added in
 GitLab EE 10.6 but is enabled by default only on GitLab EE 11.1. You can
 disable or enable this feature manually by following

doc/administration/geo/disaster_recovery/bring_primary_back.md

@@ -32,14 +32,14 @@ To bring the former **primary** node up to date:
    sudo gitlab-ctl start
    ```
 
-   NOTE: **Note:**
+   NOTE:
    If you [disabled the **primary** node permanently](index.md#step-2-permanently-disable-the-primary-node),
    you need to undo those steps now. For Debian/Ubuntu you just need to run
    `sudo systemctl enable gitlab-runsvdir`. For CentOS 6, you need to install
    the GitLab instance from scratch and set it up as a **secondary** node by
    following [Setup instructions](../setup/index.md). In this case, you don't need to follow the next step.
 
-   NOTE: **Note:**
+   NOTE:
    If you [changed the DNS records](index.md#step-4-optional-updating-the-primary-domain-dns-record)
    for this node during disaster recovery procedure you may need to [block
    all the writes to this node](planned_failover.md#prevent-updates-to-the-primary-node)

doc/administration/geo/disaster_recovery/index.md

@@ -58,7 +58,7 @@ must disable the **primary** node.
    sudo systemctl disable gitlab-runsvdir
    ```
 
-   NOTE: **Note:**
+   NOTE:
    (**CentOS only**) In CentOS 6 or older, there is no easy way to prevent GitLab from being
    started if the machine reboots isn't available (see [Omnibus GitLab issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3058)).
    It may be safest to uninstall the GitLab package completely:
@@ -67,7 +67,7 @@ must disable the **primary** node.
    yum remove gitlab-ee
    ```
 
-   NOTE: **Note:**
+   NOTE:
    (**Ubuntu 14.04 LTS**) If you are using an older version of Ubuntu
    or any other distribution based on the Upstart init system, you can prevent GitLab
    from starting if the machine reboots by doing the following:
@@ -301,7 +301,7 @@ secondary domain, like changing Git remotes and API URLs.
    external_url 'https://<new_external_url>'
    ```
 
-   NOTE: **Note:**
+   NOTE:
    Changing `external_url` won't prevent access via the old secondary URL, as
    long as the secondary DNS records are still intact.
 

doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md

@@ -58,7 +58,7 @@ What is not covered:
 
 ### Preparation
 
-NOTE: **Note:**
+NOTE:
 Before following any of those steps, make sure you have `root` access to the
 **secondary** to promote it, since there isn't provided an automated way to
 promote a Geo replica and perform a failover.
@@ -188,12 +188,12 @@ follow these steps to avoid unnecessary data loss:
      sudo systemctl disable gitlab-runsvdir
      ```
 
-     NOTE: **Note:**
+     NOTE:
      (**CentOS only**) In CentOS 6 or older, there is no easy way to prevent GitLab from being
      started if the machine reboots isn't available (see [Omnibus GitLab issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3058)).
      It may be safest to uninstall the GitLab package completely with `sudo yum remove gitlab-ee`.
 
-     NOTE: **Note:**
+     NOTE:
      (**Ubuntu 14.04 LTS**) If you are using an older version of Ubuntu
      or any other distribution based on the Upstart init system, you can prevent GitLab
      from starting if the machine reboots as `root` with
@@ -213,7 +213,7 @@ follow these steps to avoid unnecessary data loss:
 
 ### Promoting the **secondary** node
 
-NOTE: **Note:**
+NOTE:
 A new **secondary** should not be added at this time. If you want to add a new
 **secondary**, do this after you have completed the entire process of promoting
 the **secondary** to the **primary**.

doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md

@@ -46,7 +46,7 @@ What is not covered:
 
 ### Preparation
 
-NOTE: **Note:**
+NOTE:
 Before following any of those steps, make sure you have `root` access to the
 **secondary** to promote it, since there isn't provided an automated way to
 promote a Geo replica and perform a failover.
@@ -176,12 +176,12 @@ follow these steps to avoid unnecessary data loss:
      sudo systemctl disable gitlab-runsvdir
      ```
 
-     NOTE: **Note:**
+     NOTE:
      (**CentOS only**) In CentOS 6 or older, there is no easy way to prevent GitLab from being
      started if the machine reboots isn't available (see [Omnibus GitLab issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3058)).
      It may be safest to uninstall the GitLab package completely with `sudo yum remove gitlab-ee`.
 
-     NOTE: **Note:**
+     NOTE:
      (**Ubuntu 14.04 LTS**) If you are using an older version of Ubuntu
      or any other distribution based on the Upstart init system, you can prevent GitLab
      from starting if the machine reboots as `root` with

doc/administration/geo/index.md

@@ -143,11 +143,11 @@ The following table lists basic ports that must be open between the **primary**
 
 See the full list of ports used by GitLab in [Package defaults](https://docs.gitlab.com/omnibus/package-information/defaults.html)
 
-NOTE: **Note:**
+NOTE:
 [Web terminal](../../ci/environments/index.md#web-terminals) support requires your load balancer to correctly handle WebSocket connections.
 When using HTTP or HTTPS proxying, your load balancer must be configured to pass through the `Connection` and `Upgrade` hop-by-hop headers. See the [web terminal](../integration/terminal.md) integration guide for more details.
 
-NOTE: **Note:**
+NOTE:
 When using HTTPS protocol for port 443, you will need to add an SSL certificate to the load balancers.
 If you wish to terminate SSL at the GitLab application server instead, use TCP protocol.
 
@@ -155,7 +155,7 @@ If you wish to terminate SSL at the GitLab application server instead, use TCP p
 
 We recommend that if you use LDAP on your **primary** node, you also set up secondary LDAP servers on each **secondary** node. Otherwise, users will not be able to perform Git operations over HTTP(s) on the **secondary** node using HTTP Basic Authentication. However, Git via SSH and personal access tokens will still work.
 
-NOTE: **Note:**
+NOTE:
 It is possible for all **secondary** nodes to share an LDAP server, but additional latency can be an issue. Also, consider what LDAP server will be available in a [disaster recovery](disaster_recovery/index.md) scenario if a **secondary** node is promoted to be a **primary** node.
 
 Check for instructions on how to set up replication in your LDAP service. Instructions will be different depending on the software or service used. For example, OpenLDAP provides [these instructions](https://www.openldap.org/doc/admin24/replication.html).

doc/administration/geo/replication/configuration.md

@@ -9,7 +9,7 @@ type: howto
 
 ## Configuring a new **secondary** node
 
-NOTE: **Note:**
+NOTE:
 This is the final step in setting up a **secondary** Geo node. Stages of the
 setup process must be completed in the documented order.
 Before attempting the steps in this stage, [complete all prior stages](../setup/index.md#using-omnibus-gitlab).
@@ -23,7 +23,7 @@ The basic steps of configuring a **secondary** node are to:
 You are encouraged to first read through all the steps before executing them
 in your testing/production environment.
 
-NOTE: **Note:**
+NOTE:
 **Do not** set up any custom authentication for the **secondary** nodes. This will be handled by the **primary** node.
 Any change that requires access to the **Admin Area** needs to be done in the
 **primary** node because the **secondary** node is a read-only replica.
@@ -157,7 +157,7 @@ keys must be manually replicated to the **secondary** node.
    for file in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf $file; done
    ```
 
-   NOTE: **Note:**
+   NOTE:
    The output for private keys and public keys command should generate the same fingerprint.
 
 1. Restart `sshd` on your **secondary** node:

doc/administration/geo/replication/docker_registry.md

@@ -64,17 +64,17 @@ We need to make Docker Registry send notification events to the
    ]
    ```
 
-   NOTE: **Note:**
+   NOTE:
    Replace `<replace_with_a_secret_token>` with a case sensitive alphanumeric string
    that starts with a letter. You can generate one with `< /dev/urandom tr -dc _A-Z-a-z-0-9 | head -c 32 | sed "s/^[0-9]*//"; echo`
 
-   NOTE: **Note:**
+   NOTE:
    If you use an external Registry (not the one integrated with GitLab), you must add
    these settings to its configuration yourself. In this case, you will also have to specify
    notification secret in `registry.notification_secret` section of
    `/etc/gitlab/gitlab.rb` file.
 
-   NOTE: **Note:**
+   NOTE:
    If you use GitLab HA, you will also have to specify
    the notification secret in `registry.notification_secret` section of
    `/etc/gitlab/gitlab.rb` file for every web node.

doc/administration/geo/replication/location_aware_git_url.md

@@ -18,7 +18,7 @@ Though these instructions use [AWS Route53](https://aws.amazon.com/route53/),
 other services such as [Cloudflare](https://www.cloudflare.com/) could be used
 as well.
 
-NOTE: **Note:**
+NOTE:
 You can also use a load balancer to distribute web UI or API traffic to
 [multiple Geo **secondary** nodes](../../../user/admin_area/geo_nodes.md#multiple-secondary-nodes-behind-a-load-balancer).
 Importantly, the **primary** node cannot yet be included. See the feature request

doc/administration/geo/replication/multiple_servers.md

@@ -27,7 +27,7 @@ network topology of your deployment.
 The only external way to access the two Geo deployments is by HTTPS at
 `gitlab.us.example.com` and `gitlab.eu.example.com` in the example above.
 
-NOTE: **Note:**
+NOTE:
 The **primary** and **secondary** Geo deployments must be able to communicate to each other over HTTPS.
 
 ## Redis and PostgreSQL for multiple nodes
@@ -37,7 +37,7 @@ Geo supports:
 - Redis and PostgreSQL on the **primary** node configured for multiple nodes.
 - Redis on **secondary** nodes configured for multiple nodes.
 
-NOTE: **Note:**
+NOTE:
 Support for PostgreSQL on **secondary** nodes in multi-node configuration
 [is planned](https://gitlab.com/groups/gitlab-org/-/epics/2536).
 
@@ -48,7 +48,7 @@ For more information about setting up a multi-node PostgreSQL cluster and Redis
 [PostgreSQL](../../postgresql/replication_and_failover.md) and
 [Redis](../../redis/replication_and_failover.md), respectively.
 
-NOTE: **Note:**
+NOTE:
 It is possible to use cloud hosted services for PostgreSQL and Redis, but this is beyond the scope of this document.
 
 ## Prerequisites: Two working GitLab multi-node clusters
@@ -90,7 +90,7 @@ The following steps enable a GitLab cluster to serve as the **primary** node.
 
 After making these changes, [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) so the changes take effect.
 
-NOTE: **Note:**
+NOTE:
 PostgreSQL and Redis should have already been disabled on the
 application servers, and connections from the application servers to those
 services on the backend servers configured, during normal GitLab multi-node set up. See
@@ -136,13 +136,13 @@ documentation:
 - [Gitaly](../../gitaly/index.md), which will store data that is
   synchronized from the **primary** node.
 
-NOTE: **Note:**
+NOTE:
 [NFS](../../nfs.md) can be used in place of Gitaly but is not
 recommended.
 
 ### Step 2: Configure the main read-only replica PostgreSQL database on the **secondary** node
 
-NOTE: **Note:**
+NOTE:
 The following documentation assumes the database will be run on
 a single node only. Multi-node PostgreSQL on **secondary** nodes is
 [not currently supported](https://gitlab.com/groups/gitlab-org/-/epics/2536).
@@ -232,7 +232,7 @@ If using an external PostgreSQL instance, refer also to
 
 ### Step 3: Configure the tracking database on the **secondary** node
 
-NOTE: **Note:**
+NOTE:
 This documentation assumes the tracking database will be run on
 only a single machine, rather than as a PostgreSQL cluster.
 
@@ -365,14 +365,14 @@ then make the following modifications:
    registry['gid'] = 9002
    ```
 
-NOTE: **Note:**
+NOTE:
 If you had set up PostgreSQL cluster using the omnibus package and you had set
 up `postgresql['sql_user_password'] = 'md5 digest of secret'` setting, keep in
 mind that `gitlab_rails['db_password']` and `geo_secondary['db_password']`
 mentioned above contains the plaintext passwords. This is used to let the Rails
 servers connect to the databases.
 
-NOTE: **Note:**
+NOTE:
 Make sure that current node IP is listed in `postgresql['md5_auth_cidr_addresses']` setting of your remote database.
 
 After making these changes [Reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) so the changes take effect.

doc/administration/geo/replication/remove_geo_node.md

@@ -42,7 +42,7 @@ Once GitLab has been uninstalled from the **secondary** node, the replication sl
    sudo gitlab-psql
    ```
 
-   NOTE: **Note:**
+   NOTE:
    Using `gitlab-rails dbconsole` will not work, because managing replication slots requires superuser permissions.
 
 1. Find the name of the relevant replication slot. This is the slot that is specified with `--slot-name` when running the replicate command: `gitlab-ctl replicate-geo-database`.

doc/administration/geo/replication/troubleshooting.md

@@ -308,7 +308,7 @@ log data to build up in `pg_xlog`. Removing the unused slots can reduce the amou
    sudo gitlab-psql
    ```
 
-   Note: **Note:** Using `gitlab-rails dbconsole` will not work, because managing replication slots requires superuser permissions.
+   Note: Using `gitlab-rails dbconsole` will not work, because managing replication slots requires superuser permissions.
 
 1. View your replication slots with:
 

doc/administration/geo/replication/updating_the_geo_nodes.md

@@ -20,7 +20,7 @@ Updating Geo nodes involves performing:
 
 ## General update steps
 
-NOTE: **Note:**
+NOTE:
 These general update steps are not intended for [high-availability deployments](https://docs.gitlab.com/omnibus/update/README.html#multi-node--ha-deployment), and will cause downtime. If you want to avoid downtime, consider using [zero downtime updates](https://docs.gitlab.com/omnibus/update/README.html#zero-downtime-updates).
 
 To update the Geo nodes when a new GitLab version is released, update **primary**

doc/administration/geo/setup/database.md

@@ -7,13 +7,13 @@ type: howto
 
 # Geo database replication **(PREMIUM ONLY)**
 
-NOTE: **Note:**
+NOTE:
 If your GitLab installation uses external (not managed by Omnibus) PostgreSQL
 instances, the Omnibus roles will not be able to perform all necessary
 configuration steps. In this case,
 [follow the Geo with external PostgreSQL instances document instead](external_database.md).
 
-NOTE: **Note:**
+NOTE:
 The stages of the setup process must be completed in the documented order.
 Before attempting the steps in this stage, [complete all prior stages](../setup/index.md#using-omnibus-gitlab).
 
@@ -79,7 +79,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
 
 1. GitLab 10.4 and up only: Do the following to make sure the `gitlab` database user has a password defined:
 
-   NOTE: **Note:**
+   NOTE:
    Until FDW settings are removed in GitLab version 14.0, avoid using single or double quotes in the
    password for PostgreSQL as that will lead to errors when reconfiguring.
 
@@ -134,7 +134,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    connect to the **primary** node's database. For this reason, we need the address of
    each node.
 
-   NOTE: **Note:**
+   NOTE:
    For external PostgreSQL instances, see [additional instructions](external_database.md).
 
    If you are using a cloud provider, you can lookup the addresses for each
@@ -171,7 +171,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    corresponding to the given address. See [the PostgreSQL documentation](https://www.postgresql.org/docs/11/runtime-config-connection.html)
    for more details.
 
-   NOTE: **Note:**
+   NOTE:
    If you need to use `0.0.0.0` or `*` as the listen_address, you will also need to add
    `127.0.0.1/32` to the `postgresql['md5_auth_cidr_addresses']` setting, to allow Rails to connect through
    `127.0.0.1`. For more information, see [omnibus-5258](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5258).
@@ -290,7 +290,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    gitlab-ctl stop sidekiq
    ```
 
-   NOTE: **Note:**
+   NOTE:
    This step is important so we don't try to execute anything before the node is fully configured.
 
 1. [Check TCP connectivity](../../raketasks/maintenance.md) to the **primary** node's PostgreSQL server:
@@ -299,7 +299,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    gitlab-rake gitlab:tcp_check[<primary_node_ip>,5432]
    ```
 
-   NOTE: **Note:**
+   NOTE:
    If this step fails, you may be using the wrong IP address, or a firewall may
    be preventing access to the server. Check the IP address, paying close
    attention to the difference between public and private addresses and ensure
@@ -431,10 +431,10 @@ data before running `pg_basebackup`.
       --host=<primary_node_ip>
    ```
 
-   NOTE: **Note:**
+   NOTE:
    Replication slot names must only contain lowercase letters, numbers, and the underscore character.
 
-   NOTE: **Note:**
+   NOTE:
    In GitLab 13.4, a seed project is added when GitLab is first installed. This makes it necessary to pass `--force` even
    on a new Geo secondary node. There is an [issue to account for seed projects](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5618)
    when checking the database.

doc/administration/geo/setup/external_database.md

@@ -11,7 +11,7 @@ This document is relevant if you are using a PostgreSQL instance that is *not
 managed by Omnibus*. This includes cloud-managed instances like AWS RDS, or
 manually installed and configured PostgreSQL instances.
 
-NOTE: **Note:**
+NOTE:
 We strongly recommend running Omnibus-managed instances as they are actively
 developed and tested. We aim to be compatible with most external
 (not managed by Omnibus) databases but we do not guarantee compatibility.
@@ -186,7 +186,7 @@ to grant additional roles to your tracking database user (by default, this is
 If you have an external database ready to be used as the tracking database,
 follow the instructions below to use it:
 
-NOTE: **Note:**
+NOTE:
 If you want to use AWS RDS as a tracking database, make sure it has access to
 the secondary database. Unfortunately, just assigning the same security group is not enough as
 outbound rules do not apply to RDS PostgreSQL databases. Therefore, you need to explicitly add an inbound

doc/administration/git_annex.md

@@ -94,7 +94,7 @@ one is located in `config.yml` of GitLab Shell.
 
 ## Using GitLab git-annex
 
-NOTE: **Note:**
+NOTE:
 Your Git remotes must be using the SSH protocol, not HTTP(S).
 
 Here is an example workflow of uploading a very large file and then checking it

doc/administration/gitaly/index.md

@@ -69,7 +69,7 @@ this default configuration used by:
 However, Gitaly can be deployed to its own server, which can benefit GitLab installations that span
 multiple machines.
 
-NOTE: **Note:**
+NOTE:
 When configured to run on their own servers, Gitaly servers
 [must be upgraded](https://docs.gitlab.com/omnibus/update/#upgrading-gitaly-servers) before Gitaly
 clients in your cluster.
@@ -141,7 +141,7 @@ We assume your GitLab installation has three repository storages:
 
 You can use as few as one server with one repository storage if desired.
 
-NOTE: **Note:**
+NOTE:
 The token referred to throughout the Gitaly documentation is just an arbitrary password selected by
 the administrator. It is unrelated to tokens created for the GitLab API or other similar web API
 tokens.
@@ -434,7 +434,7 @@ server (with `gitaly_address`) unless you setup with special
            path: /some/local/path
    ```
 
-   NOTE: **Note:**
+   NOTE:
    `/some/local/path` should be set to a local folder that exists, however no data is stored in
    this folder. This requirement is scheduled to be removed when
    [this issue](https://gitlab.com/gitlab-org/gitaly/-/issues/1282) is resolved.
@@ -647,7 +647,7 @@ To configure Gitaly with TLS:
            path: /some/local/path
    ```
 
-   NOTE: **Note:**
+   NOTE:
    `/some/local/path` should be set to a local folder that exists, however no data is stored
    in this folder. This requirement is scheduled to be removed when
    [Gitaly issue #1282](https://gitlab.com/gitlab-org/gitaly/-/issues/1282) is resolved.
@@ -723,7 +723,7 @@ We recommend:
 - At least 300MB memory per worker.
 - No more than one worker per core.
 
-NOTE: **Note:**
+NOTE:
 `gitaly-ruby` is planned to be eventually removed. To track progress, see the
 [Remove the Gitaly-Ruby sidecar](https://gitlab.com/groups/gitlab-org/-/epics/2862) epic.
 
@@ -805,7 +805,7 @@ You can observe the behavior of this queue using the Gitaly logs and Prometheus:
   - `gitaly_rate_limiting_queued`.
   - `gitaly_rate_limiting_seconds`.
 
-NOTE: **Note:**
+NOTE:
 Though the name of the Prometheus metric contains `rate_limiting`, it is a concurrency limiter, not
 a rate limiter. If a Gitaly client makes 1000 requests in a row very quickly, concurrency does not
 exceed 1 and the concurrency limiter has no effect.

doc/administration/gitaly/praefect.md

@@ -12,7 +12,7 @@ be run in a clustered configuration to increase fault tolerance. In this
 configuration, every Git repository is stored on every Gitaly node in the
 cluster. Multiple clusters (or shards), can be configured.
 
-NOTE: **Note:**
+NOTE:
 Gitaly Clusters can be created using [GitLab Core](https://about.gitlab.com/pricing/#self-managed)
 and higher tiers. However, technical support is limited to GitLab Premium and Ultimate customers
 only. Not available in GitLab.com.
@@ -188,7 +188,7 @@ We note in the instructions below where these secrets are required.
 
 ### PostgreSQL
 
-NOTE: **Note:**
+NOTE:
 Do not store the GitLab application database and the Praefect
 database on the same PostgreSQL server if using
 [Geo](../geo/index.md). The replication state is internal to each instance
@@ -287,7 +287,7 @@ The `praefect` user and its password should be included in the file (default is
 `userlist.txt`) used by PgBouncer if the [`auth_file`](https://www.pgbouncer.org/config.html#auth_file)
 configuration option is set.
 
-NOTE: **Note:**
+NOTE:
 By default PgBouncer uses port `6432` to accept incoming
 connections. You can change it by setting the [`listen_port`](https://www.pgbouncer.org/config.html#listen_port)
 configuration option. We recommend setting it to the default port value (`5432`) used by
@@ -298,7 +298,7 @@ PostgreSQL instances. Otherwise you should change the configuration parameter
 
 > [Introduced](https://gitlab.com/gitlab-org/gitaly/-/issues/2634) in GitLab 13.4, Praefect nodes can no longer be designated as `primary`.
 
-NOTE: **Note:**
+NOTE:
 If there are multiple Praefect nodes, complete these steps for **each** node.
 
 To complete this section you need a [configured PostgreSQL server](#postgresql), including:
@@ -573,7 +573,7 @@ To configure Praefect with TLS:
            path: /some/local/path
    ```
 
-   NOTE: **Note:**
+   NOTE:
    `/some/local/path` should be set to a local folder that exists, however no
    data is stored in this folder. This requirement is scheduled to be removed when
    [this issue](https://gitlab.com/gitlab-org/gitaly/-/issues/1282) is resolved.
@@ -602,7 +602,7 @@ To configure Praefect with TLS:
 
 ### Gitaly
 
-NOTE: **Note:**
+NOTE:
 Complete these steps for **each** Gitaly node.
 
 To complete this section you need:
@@ -763,7 +763,7 @@ internal traffic from the GitLab application to the Praefect nodes. The
 specifics on which load balancer to use or the exact configuration is beyond the
 scope of the GitLab documentation.
 
-NOTE: **Note:**
+NOTE:
 The load balancer must be configured to accept traffic from the Gitaly nodes in
 addition to the GitLab nodes. Some requests handled by
 [`gitaly-ruby`](index.md#gitaly-ruby) sidecar processes call into the main Gitaly
@@ -1116,7 +1116,7 @@ available:
 - In GitLab 13.3 and later, `-partially-replicated` that specifies whether to display a list of
   [outdated replicas of writable repositories](#outdated-replicas-of-writable-repositories).
 
-NOTE: **Note:**
+NOTE:
 `dataloss` is still in beta and the output format is subject to change.
 
 To check for outdated replicas of read-only repositories, run:
@@ -1278,7 +1278,7 @@ Gitaly Cluster automatically.
 
 Repositories may be moved from one storage location using the [Project repository storage moves API](../../api/project_repository_storage_moves.md):
 
-NOTE: **Note:**
+NOTE:
 The Project repository storage moves API [cannot move all repository types](../../api/project_repository_storage_moves.md#limitations).
 
 To move repositories to Gitaly Cluster:

doc/administration/incoming_email.md

@@ -253,7 +253,7 @@ incoming_email:
 
 Example configuration for Gmail/G Suite. Assumes mailbox `gitlab-incoming@gmail.com`.
 
-NOTE: **Note:**
+NOTE:
 `incoming_email_email` cannot be a Gmail alias account.
 
 Example for Omnibus installs:
@@ -442,7 +442,7 @@ Example configurations for Microsoft Office 365 with IMAP enabled.
 
 ##### Sub-addressing mailbox
 
-NOTE: **Note:**
+NOTE:
 As of September 2020 sub-addressing support
 [has been added to Office 365](https://office365.uservoice.com/forums/273493-office-365-admin/suggestions/18612754-support-for-dynamic-email-aliases-in-office-36). This feature is not
 enabled by default, and must be enabled through PowerShell.
@@ -451,7 +451,7 @@ This series of PowerShell commands enables [sub-addressing](#email-sub-addressin
 at the organization level in Office 365. This allows all mailboxes in the organization
 to receive sub-addressed mail:
 
-NOTE: **Note:**
+NOTE:
 This series of commands enables sub-addressing at the organization
 level in Office 365. This allows all mailboxes in the organization
 to receive sub-addressed mail.

doc/administration/integration/plantuml.md

@@ -137,7 +137,7 @@ that, login with an Admin account and do following:
 - Check **Enable PlantUML** checkbox.
 - Set the PlantUML instance as `https://gitlab.example.com/-/plantuml/`.
 
-NOTE: **Note:**
+NOTE:
 If you are using a PlantUML server running v1.2020.9 and
 above (for example, [plantuml.com](https://plantuml.com)), set the `PLANTUML_ENCODING`
 environment variable to enable the `deflate` compression. On Omnibus,

doc/administration/integration/terminal.md

@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7690) in GitLab 8.15.
 
-NOTE: **Note:**
+NOTE:
 Only project maintainers and owners can access web terminals.
 
 With the introduction of the [Kubernetes integration](../../user/project/clusters/index.md),
@@ -51,7 +51,7 @@ detail below.
 
 ## Enabling and disabling terminal support
 
-NOTE: **Note:**
+NOTE:
 AWS Elastic Load Balancers (ELBs) do not support web sockets.
 AWS Application Load Balancers (ALBs) must be used if you want web terminals
 to work. See [AWS Elastic Load Balancing Product Comparison](https://aws.amazon.com/elasticloadbalancing/features/#compare)

doc/administration/issue_closing_pattern.md

@@ -7,7 +7,7 @@ type: reference
 
 # Issue closing pattern **(CORE ONLY)**
 
-NOTE: **Note:**
+NOTE:
 This is the administration documentation. There is a separate [user documentation](../user/project/issues/managing_issues.md#closing-issues-automatically)
 on issue closing pattern.
 

doc/administration/job_artifacts.md

@@ -111,7 +111,7 @@ In a multi-server setup you must use one of the options to
 
 #### Object Storage Settings
 
-NOTE: **Note:**
+NOTE:
 In GitLab 13.2 and later, we recommend using the
 [consolidated object storage settings](object_storage.md#consolidated-object-storage-configuration).
 This section describes the earlier configuration format.
@@ -507,7 +507,7 @@ If you need to manually remove job artifacts associated with multiple jobs while
 
 1. Delete job artifacts older than a specific date:
 
-   NOTE: **Note:**
+   NOTE:
    This step also erases artifacts that users have chosen to
    ["keep"](../ci/pipelines/job_artifacts.md#browsing-artifacts).
 

doc/administration/job_logs.md

@@ -132,7 +132,7 @@ find /var/opt/gitlab/gitlab-rails/shared/artifacts -name "job.log" -mtime +60 -d
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18169) in GitLab 10.4.
 
-NOTE: **Note:**
+NOTE:
 This beta feature is off by default. See below for how to [enable or disable](#enabling-incremental-logging) it.
 
 By combining the process with object storage settings, we can completely bypass
@@ -184,8 +184,8 @@ Feature.enabled?(:ci_enable_live_trace)
 Feature.enable(:ci_enable_live_trace)
 ```
 
-NOTE: **Note:**
-The transition period is handled gracefully. Upcoming logs are
+NOTE:
+The transition period is handled gracefully. Upcoming logs are 
 generated with the incremental architecture, and on-going logs stay with the
 legacy architecture, which means that on-going logs aren't forcibly
 re-generated with the incremental architecture.
@@ -196,7 +196,7 @@ re-generated with the incremental architecture.
 Feature.disable('ci_enable_live_trace')
 ```
 
-NOTE: **Note:**
+NOTE:
 The transition period is handled gracefully. Upcoming logs are generated
 with the legacy architecture, and on-going incremental logs stay with the incremental
 architecture, which means that on-going incremental logs aren't forcibly re-generated

doc/administration/lfs/index.md

@@ -71,7 +71,7 @@ GitLab provides two different options for the uploading mechanism: "Direct uploa
 
 [Read more about using object storage with GitLab](../object_storage.md).
 
-NOTE: **Note:**
+NOTE:
 In GitLab 13.2 and later, we recommend using the
 [consolidated object storage settings](../object_storage.md#consolidated-object-storage-configuration).
 This section describes the earlier configuration format.

doc/administration/logs.md

@@ -117,7 +117,7 @@ The ActionCable connection or channel class is used as the `controller`.
 }
 ```
 
-NOTE: **Note:**
+NOTE:
 Starting with GitLab 12.5, if an error occurs, an
 `exception` field is included with `class`, `message`, and
 `backtrace`. Previous versions included an `error` field instead of
@@ -383,7 +383,7 @@ only. For example:
 
 ## `audit_json.log`
 
-NOTE: **Note:**
+NOTE:
 Most log entries only exist in [GitLab Starter](https://about.gitlab.com/pricing/), however a few exist in GitLab Core.
 
 This file lives in `/var/log/gitlab/gitlab-rails/audit_json.log` for
@@ -1004,7 +1004,7 @@ When [troubleshooting](troubleshooting/index.md) issues that aren't localized to
 previously listed components, it's helpful to simultaneously gather multiple logs and statistics
 from a GitLab instance.
 
-NOTE: **Note:**
+NOTE:
 GitLab Support will often ask for one of these, and maintains the required tools.
 
 ### Briefly tail the main logs

doc/administration/merge_request_diffs.md

@@ -102,7 +102,7 @@ be configured already.
 
 ### Object Storage Settings
 
-NOTE: **Note:**
+NOTE:
 In GitLab 13.2 and later, we recommend using the
 [consolidated object storage settings](object_storage.md#consolidated-object-storage-configuration).
 This section describes the earlier configuration format.

doc/administration/monitoring/ip_whitelist.md

@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > Introduced in GitLab 9.4.
 
-NOTE: **Note:**
+NOTE:
 We intend to [rename IP whitelist as `IP allowlist`](https://gitlab.com/gitlab-org/gitlab/-/issues/7554).
 
 GitLab provides some [monitoring endpoints](../../user/admin_area/monitoring/health_check.md)

doc/administration/nfs.md

@@ -118,7 +118,7 @@ To disable NFS server delegation, do the following:
 
 1. Restart the NFS server process. For example, on CentOS run `service nfs restart`.
 
-NOTE: **Note:**
+NOTE:
 The kernel bug may be fixed in
 [more recent kernels with this commit](https://github.com/torvalds/linux/commit/95da1b3a5aded124dd1bda1e3cdb876184813140).
 Red Hat Enterprise 7 [shipped a kernel update](https://access.redhat.com/errata/RHSA-2019:2029)
@@ -133,7 +133,7 @@ NFS performance with GitLab can in some cases be improved with
 [direct Git access](gitaly/index.md#direct-access-to-git-in-gitlab) using
 [Rugged](https://github.com/libgit2/rugged).
 
-NOTE: **Note:**
+NOTE:
 From GitLab 12.1, it will automatically be detected if Rugged can and should be used per storage.
 
 If you previously enabled Rugged using the feature flag, you will need to unset the feature flag by using:
@@ -146,7 +146,7 @@ If the Rugged feature flag is explicitly set to either `true` or `false`, GitLab
 
 #### Improving NFS performance with Puma
 
-NOTE: **Note:**
+NOTE:
 From GitLab 12.7, Rugged is not automatically enabled if Puma thread count is greater than `1`.
 
 If you want to use Rugged with Puma, [set Puma thread count to `1`](https://docs.gitlab.com/omnibus/settings/puma.html#puma-settings).

doc/administration/operations/cleaning_up_redis_sessions.md

@@ -21,7 +21,7 @@ prefixed with `session:gitlab:`, so they would look like
 `session:gitlab:976aa289e2189b17d7ef525a6702ace9`. Below we describe how to
 remove the keys in the old format.
 
-NOTE: **Note:**
+NOTE:
 The instructions below must be modified in accordance with your
 configuration settings if you have used the advanced Redis
 settings outlined in

doc/administration/operations/extra_sidekiq_processes.md

@@ -11,7 +11,7 @@ These processes can be used to consume a dedicated set
 of queues. This can be used to ensure certain queues always have dedicated
 workers, no matter the number of jobs that need to be processed.
 
-NOTE: **Note:**
+NOTE:
 The information in this page applies only to Omnibus GitLab.
 
 ## Available Sidekiq queues

doc/administration/operations/fast_ssh_key_lookup.md

@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1631) in [GitLab Starter](https://about.gitlab.com/pricing/) 9.3.
 > - [Available in](https://gitlab.com/gitlab-org/gitlab/-/issues/3953) GitLab Community Edition 10.4.
 
-NOTE: **Note:**
+NOTE:
 This document describes a drop-in replacement for the
 `authorized_keys` file. For normal (non-deploy key) users, consider using
 [SSH certificates](ssh_certificates.md). They are even faster, but are not a
@@ -80,11 +80,11 @@ Confirm that SSH is working by commenting out your user's key in the `authorized
 A successful pull would mean that GitLab was able to find the key in the database,
 since it is not present in the file anymore.
 
-NOTE: **Note:**
+NOTE:
 For Omnibus Docker, `AuthorizedKeysCommand` is setup by default in
 GitLab 11.11 and later.
 
-NOTE: **Note:**
+NOTE:
 For Installations from source, the command would be located at
 `/home/git/gitlab-shell/bin/gitlab-shell-authorized-keys-check` if [the install from source](../../install/installation.md#install-gitlab-shell) instructions were followed.
 You might want to consider creating a wrapper script somewhere else since this command needs to be

doc/administration/operations/filesystem_benchmarking.md

@@ -71,7 +71,7 @@ operations per second.
 
 ### Simple benchmarking
 
-NOTE: **Note:**
+NOTE:
 This test is naive but may be useful if `fio` is not
 available on the system. It's possible to receive good results on this
 test but still have poor performance due to read speed and various other

doc/administration/operations/unicorn.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Understanding Unicorn and unicorn-worker-killer
 
-NOTE: **Note:**
+NOTE:
 Starting with GitLab 13.0, Puma is the default web server used in GitLab
 all-in-one package based installations as well as GitLab Helm chart deployments.
 

doc/administration/packages/dependency_proxy.md

@@ -16,7 +16,7 @@ dependency proxies, see the [user guide](../../user/packages/dependency_proxy/in
 
 ## Enabling the Dependency Proxy feature
 
-NOTE: **Note:**
+NOTE:
 Dependency proxy requires the Puma web server to be enabled.
 
 To enable the dependency proxy feature:
@@ -88,7 +88,7 @@ store the blobs of the dependency proxy.
 
 [Read more about using object storage with GitLab](../object_storage.md).
 
-NOTE: **Note:**
+NOTE:
 In GitLab 13.2 and later, we recommend using the
 [consolidated object storage settings](../object_storage.md#consolidated-object-storage-configuration).
 This section describes the earlier configuration format.

doc/administration/packages/index.md

@@ -53,7 +53,7 @@ guides you through the process.
 
 ## Enabling the Packages feature
 
-NOTE: **Note:**
+NOTE:
 After the Packages feature is enabled, the repositories are available
 for all new projects by default. To enable it for existing projects, users
 explicitly do so in the project's settings.
@@ -136,7 +136,7 @@ store packages.
 
 [Read more about using object storage with GitLab](../object_storage.md).
 
-NOTE: **Note:**
+NOTE:
 We recommend using the [consolidated object storage settings](../object_storage.md#consolidated-object-storage-configuration). The following instructions apply to the original config format.
 
 **Omnibus GitLab installations**

doc/administration/pages/index.md

@@ -16,7 +16,7 @@ description: 'Learn how to administer GitLab Pages.'
 GitLab Pages allows for hosting of static sites. It must be configured by an
 administrator. Separate [user documentation](../../user/project/pages/index.md) is available.
 
-NOTE: **Note:**
+NOTE:
 This guide is for Omnibus GitLab installations. If you have installed
 GitLab from source, see
 [GitLab Pages administration for source installations](source.md).
@@ -68,7 +68,7 @@ Before proceeding with the Pages configuration, you will need to:
    so that your users don't have to bring their own.
 1. (Only for custom domains) Have a **secondary IP**.
 
-NOTE: **Note:**
+NOTE:
 If your GitLab instance and the Pages daemon are deployed in a private network or behind a firewall, your GitLab Pages websites will only be accessible to devices/users that have access to the private network.
 
 ### Add the domain to the Public Suffix List
@@ -101,7 +101,7 @@ where `example.io` is the domain under which GitLab Pages will be served
 and `192.0.2.1` is the IPv4 address of your GitLab instance and `2001::1` is the
 IPv6 address. If you don't have IPv6, you can omit the AAAA record.
 
-NOTE: **Note:**
+NOTE:
 You should not use the GitLab domain to serve user pages. For more information see the [security section](#security).
 
 ## Configuration
@@ -181,7 +181,7 @@ behavior:
 
 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 
-NOTE: **Note:**
+NOTE:
 `inplace_chroot` option might not work with the other features, such as [Pages Access Control](#access-control).
 The [GitLab Pages README](https://gitlab.com/gitlab-org/gitlab-pages#caveats) has more information about caveats and workarounds.
 

doc/administration/pages/source.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # GitLab Pages administration for source installations
 
-NOTE: **Note:**
+NOTE:
 Before attempting to enable GitLab Pages, first make sure you have
 [installed GitLab](../../install/installation.md) successfully.
 
@@ -77,7 +77,7 @@ host that GitLab runs. For example, an entry would look like this:
 where `example.io` is the domain under which GitLab Pages will be served
 and `192.0.2.1` is the IP address of your GitLab instance.
 
-NOTE: **Note:**
+NOTE:
 You should not use the GitLab domain to serve user pages. For more information
 see the [security section](#security).
 
@@ -349,7 +349,7 @@ world. Custom domains and TLS are supported.
 
 ## NGINX caveats
 
-NOTE: **Note:**
+NOTE:
 The following information applies only for installations from source.
 
 Be extra careful when setting up the domain name in the NGINX configuration. You must

doc/administration/postgresql/pgbouncer.md

@@ -36,7 +36,7 @@ This content has been moved to a [new location](replication_and_failover.md#conf
 
 1. Run `gitlab-ctl reconfigure`
 
-   NOTE: **Note:**
+   NOTE:
    If the database was already running, it will need to be restarted after reconfigure by running `gitlab-ctl restart postgresql`.
 
 1. On the node you are running PgBouncer on, make sure the following is set in `/etc/gitlab/gitlab.rb`

doc/administration/postgresql/replication_and_failover.md

@@ -35,7 +35,7 @@ You also need to take into consideration the underlying network topology, making
 sure you have redundant connectivity between all Database and GitLab instances
 to avoid the network becoming a single point of failure.
 
-NOTE: **Note:**
+NOTE:
 As of GitLab 13.3, PostgreSQL 12 is shipped with Omnibus GitLab. Clustering for PostgreSQL 12 is only supported with
 Patroni. See the [Patroni](#patroni) section for further details. The support for repmgr will not be extended beyond
 PostgreSQL 11.
@@ -460,7 +460,7 @@ Check the [Troubleshooting section](#troubleshooting) before proceeding.
    # END user configuration
    ```
 
-   NOTE: **Note:**
+   NOTE:
    `pgbouncer_role` was introduced with GitLab 10.3.
 
 1. Run `gitlab-ctl reconfigure`
@@ -1148,7 +1148,7 @@ If you're running into an issue with a component not outlined here, be sure to c
 
 ## Patroni
 
-NOTE: **Note:**
+NOTE:
 Starting from GitLab 13.1, Patroni is available for **experimental** use to replace repmgr. Due to its
 experimental nature, Patroni support is **subject to change without notice.**
 
@@ -1345,7 +1345,7 @@ You can switch an exiting database cluster to use Patroni instead of repmgr with
    sudo gitlab-ctl stop postgresql
    ```
 
-   NOTE: **Note:**
+   NOTE:
    Ensure that there is no `walsender` process running on the primary node.
    `ps aux | grep walsender` must not show any running process.
 
@@ -1401,7 +1401,7 @@ Considering these, you should carefully plan your PostgreSQL upgrade:
    gitlab-ctl patroni members
    ```
 
-   NOTE: **Note:**
+   NOTE:
    `gitlab-ctl pg-upgrade` tries to detect the role of the node. If for any reason the auto-detection
    does not work or you believe it did not detect the role correctly, you can use the `--leader` or `--replica`
    arguments to manually override it.
@@ -1446,7 +1446,7 @@ Considering these, you should carefully plan your PostgreSQL upgrade:
    sudo gitlab-ctl pg-upgrade -V 12
    ```
 
-NOTE: **Note:**
+NOTE:
 Reverting PostgreSQL upgrade with `gitlab-ctl revert-pg-upgrade` has the same considerations as
 `gitlab-ctl pg-upgrade`. You should follow the same procedure by first stopping the replicas,
 then reverting the leader, and finally reverting the replicas.

doc/administration/postgresql/standalone.md

@@ -59,7 +59,7 @@ together with Omnibus GitLab. This is recommended as part of our
    gitlab_rails['auto_migrate'] = false
    ```
 
-   NOTE: **Note:**
+   NOTE:
    The role `postgres_role` was introduced with GitLab 10.3
 
 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.

doc/administration/raketasks/ldap.md

@@ -42,7 +42,7 @@ The following task will run a [group sync](../auth/ldap/index.md#group-sync) imm
 when you'd like to update all configured group memberships against LDAP without
 waiting for the next scheduled group sync to be run.
 
-NOTE: **Note:**
+NOTE:
 If you'd like to change the frequency at which a group sync is performed,
 [adjust the cron schedule](../auth/ldap/index.md#adjusting-ldap-group-sync-schedule)
 instead.

doc/administration/raketasks/uploads/migrate.md

@@ -55,7 +55,7 @@ The Rake task uses three parameters to find uploads to migrate:
 | `model_class`    | string        | Type of the model to migrate from.                     |
 | `mount_point`    | string/symbol | Name of the model's column the uploader is mounted on. |
 
-NOTE: **Note:**
+NOTE:
 These parameters are mainly internal to GitLab's structure, you may want to refer to the task list
 instead below.
 

doc/administration/redis/replication_and_failover.md

@@ -7,11 +7,11 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Redis replication and failover with Omnibus GitLab **(PREMIUM ONLY)**
 
-NOTE: **Note:**
+NOTE:
 This is the documentation for the Omnibus GitLab packages. For using your own
 non-bundled Redis, follow the [relevant documentation](replication_and_failover_external.md).
 
-NOTE: **Note:**
+NOTE:
 In Redis lingo, primary is called master. In this document, primary is used
 instead of master, except the settings where `master` is required.
 
@@ -162,7 +162,7 @@ is not achieved (see the odd number of nodes requirement above). In that case,
 a new attempt will be made after the amount of time defined in
 `sentinel['failover_timeout']` (in milliseconds).
 
-NOTE: **Note:**
+NOTE:
 We will see where `sentinel['failover_timeout']` is defined later.
 
 The `failover_timeout` variable has a lot of different use cases. According to
@@ -194,7 +194,7 @@ It is assumed that you have installed GitLab and all its components from scratch
 If you already have Redis installed and running, read how to
 [switch from a single-machine installation](#switching-from-an-existing-single-machine-installation).
 
-NOTE: **Note:**
+NOTE:
 Redis nodes (both primary and replica) will need the same password defined in
 `redis['password']`. At any time during a failover the Sentinels can
 reconfigure a node and change its status from primary to replica and vice versa.
@@ -277,7 +277,7 @@ If you fail to replicate first, you may loose data (unprocessed background jobs)
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
-NOTE: **Note:**
+NOTE:
 You can specify multiple roles like sentinel and Redis as:
 `roles ['redis_sentinel_role', 'redis_master_role']`.
 Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
@@ -327,7 +327,7 @@ Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 1. Go through the steps again for all the other replica nodes.
 
-NOTE: **Note:**
+NOTE:
 You can specify multiple roles like sentinel and Redis as:
 `roles ['redis_sentinel_role', 'redis_master_role']`.
 Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
@@ -339,7 +339,7 @@ the same Sentinels.
 
 ### Step 3. Configuring the Redis Sentinel instances
 
-NOTE: **Note:**
+NOTE:
 If you are using an external Redis Sentinel instance, be sure
 to exclude the `requirepass` parameter from the Sentinel
 configuration. This parameter will cause clients to report `NOAUTH
@@ -465,7 +465,7 @@ the correct credentials for the Sentinel nodes.
 While it doesn't require a list of all Sentinel nodes, in case of a failure,
 it needs to access at least one of the listed.
 
-NOTE: **Note:**
+NOTE:
 The following steps should be performed in the GitLab application server
 which ideally should not have Redis or Sentinels on it for a HA setup.
 
@@ -690,7 +690,7 @@ To make this work with Sentinel:
    sudo gitlab-ctl reconfigure
    ```
 
-NOTE: **Note:**
+NOTE:
 For each persistence class, GitLab will default to using the
 configuration specified in `gitlab_rails['redis_sentinels']` unless
 overridden by the previously described settings.

doc/administration/reference_architectures/10k_users.md

@@ -316,7 +316,7 @@ The following IPs will be used as an example:
 - `10.6.0.12`: Consul 2
 - `10.6.0.13`: Consul 3
 
-NOTE: **Note:**
+NOTE:
 The configuration processes for the other servers in your reference architecture will
 use the `/etc/gitlab/gitlab-secrets.json` file from your Consul server to connect
 with the other servers.
@@ -1037,7 +1037,7 @@ servers. The following IPs will be used as an example:
 - `10.6.0.72`: Sentinel - Cache 2
 - `10.6.0.73`: Sentinel - Cache 3
 
-NOTE: **Note:**
+NOTE:
 If you're using an external Redis Sentinel instance, be sure to exclude the
 `requirepass` parameter from the Sentinel configuration. This parameter causes
 clients to report `NOAUTH Authentication required.`.
@@ -1301,7 +1301,7 @@ servers. The following IPs will be used as an example:
 - `10.6.0.82`: Sentinel - Queues 2
 - `10.6.0.83`: Sentinel - Queues 3
 
-NOTE: **Note:**
+NOTE:
 If you're using an external Redis Sentinel instance, be sure to exclude the
 `requirepass` parameter from the Sentinel configuration. This parameter causes
 clients to report `NOAUTH Authentication required.`.
@@ -1422,7 +1422,7 @@ To configure the Sentinel Queues server:
 
 ## Configure Gitaly
 
-NOTE: **Note:**
+NOTE:
 [Gitaly Cluster](../gitaly/praefect.md) support
 for the Reference Architectures is being
 worked on as a [collaborative effort](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/1) between the Quality Engineering and Gitaly teams. When this component has been verified
@@ -1456,7 +1456,7 @@ Be sure to note the following items:
   to restrict access to the Gitaly server. Another option is to
   [use TLS](#gitaly-tls-support).
 
-NOTE: **Note:**
+NOTE:
 The token referred to throughout the Gitaly documentation is an arbitrary
 password selected by the administrator. This token is unrelated to tokens
 created for the GitLab API or other similar web API tokens.
@@ -1574,7 +1574,7 @@ nodes (including the Gitaly node using the certificate) and on all client nodes
 that communicate with it following the procedure described in
 [GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
 
-NOTE: **Note:**
+NOTE:
 The self-signed certificate must specify the address you use to access the
 Gitaly server. If you are addressing the Gitaly server by a hostname, you can
 either use the Common Name field for this, or add it as a Subject Alternative

doc/administration/reference_architectures/25k_users.md

@@ -316,7 +316,7 @@ The following IPs will be used as an example:
 - `10.6.0.12`: Consul 2
 - `10.6.0.13`: Consul 3
 
-NOTE: **Note:**
+NOTE:
 The configuration processes for the other servers in your reference architecture will
 use the `/etc/gitlab/gitlab-secrets.json` file from your Consul server to connect
 with the other servers.
@@ -1037,7 +1037,7 @@ servers. The following IPs will be used as an example:
 - `10.6.0.72`: Sentinel - Cache 2
 - `10.6.0.73`: Sentinel - Cache 3
 
-NOTE: **Note:**
+NOTE:
 If you're using an external Redis Sentinel instance, be sure to exclude the
 `requirepass` parameter from the Sentinel configuration. This parameter causes
 clients to report `NOAUTH Authentication required.`.
@@ -1301,7 +1301,7 @@ servers. The following IPs will be used as an example:
 - `10.6.0.82`: Sentinel - Queues 2
 - `10.6.0.83`: Sentinel - Queues 3
 
-NOTE: **Note:**
+NOTE:
 If you're using an external Redis Sentinel instance, be sure to exclude the
 `requirepass` parameter from the Sentinel configuration. This parameter causes
 clients to report `NOAUTH Authentication required.`.
@@ -1422,7 +1422,7 @@ To configure the Sentinel Queues server:
 
 ## Configure Gitaly
 
-NOTE: **Note:**
+NOTE:
 [Gitaly Cluster](../gitaly/praefect.md) support
 for the Reference Architectures is being
 worked on as a [collaborative effort](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/1) between the Quality Engineering and Gitaly teams. When this component has been verified
@@ -1456,7 +1456,7 @@ Be sure to note the following items:
   to restrict access to the Gitaly server. Another option is to
   [use TLS](#gitaly-tls-support).
 
-NOTE: **Note:**
+NOTE:
 The token referred to throughout the Gitaly documentation is an arbitrary
 password selected by the administrator. This token is unrelated to tokens
 created for the GitLab API or other similar web API tokens.
@@ -1574,7 +1574,7 @@ nodes (including the Gitaly node using the certificate) and on all client nodes
 that communicate with it following the procedure described in
 [GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
 
-NOTE: **Note:**
+NOTE:
 The self-signed certificate must specify the address you use to access the
 Gitaly server. If you are addressing the Gitaly server by a hostname, you can
 either use the Common Name field for this, or add it as a Subject Alternative

doc/administration/reference_architectures/2k_users.md

@@ -396,7 +396,7 @@ are supported and can be added if needed.
 
 ## Configure Gitaly
 
-NOTE: **Note:**
+NOTE:
 [Gitaly Cluster](../gitaly/praefect.md) support
 for the Reference Architectures is being
 worked on as a [collaborative effort](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/1) between the Quality Engineering and Gitaly teams. When this component has been verified
@@ -431,7 +431,7 @@ Be sure to note the following items:
   to restrict access to the Gitaly server. Another option is to
   [use TLS](#gitaly-tls-support).
 
-NOTE: **Note:**
+NOTE:
 The token referred to throughout the Gitaly documentation is an arbitrary
 password selected by the administrator. This token is unrelated to tokens
 created for the GitLab API or other similar web API tokens.
@@ -525,7 +525,7 @@ nodes (including the Gitaly node using the certificate) and on all client nodes
 that communicate with it following the procedure described in
 [GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
 
-NOTE: **Note:**
+NOTE:
 The self-signed certificate must specify the address you use to access the
 Gitaly server. If you are addressing the Gitaly server by a hostname, you can
 either use the Common Name field for this, or add it as a Subject Alternative

doc/administration/reference_architectures/3k_users.md

@@ -11,7 +11,7 @@ This page describes GitLab reference architecture for up to 3,000 users. For a
 full list of reference architectures, see
 [Available reference architectures](index.md#available-reference-architectures).
 
-NOTE: **Note:**
+NOTE:
 This reference architecture is designed to help your organization achieve a
 highly-available GitLab deployment. If you do not have the expertise or need to
 maintain a highly-available environment, you can have a simpler and less
@@ -500,7 +500,7 @@ servers. The following IPs will be used as an example:
 - `10.6.0.12`: Consul/Sentinel 2
 - `10.6.0.13`: Consul/Sentinel 3
 
-NOTE: **Note:**
+NOTE:
 If you're using an external Redis Sentinel instance, be sure to exclude the
 `requirepass` parameter from the Sentinel configuration. This parameter causes
 clients to report `NOAUTH Authentication required.`.
@@ -1114,7 +1114,7 @@ Refer to your preferred Load Balancer's documentation for further guidance.
 
 ## Configure Gitaly
 
-NOTE: **Note:**
+NOTE:
 [Gitaly Cluster](../gitaly/praefect.md) support
 for the Reference Architectures is being
 worked on as a [collaborative effort](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/1) between the Quality Engineering and Gitaly teams. When this component has been verified
@@ -1148,7 +1148,7 @@ Be sure to note the following items:
   to restrict access to the Gitaly server. Another option is to
   [use TLS](#gitaly-tls-support).
 
-NOTE: **Note:**
+NOTE:
 The token referred to throughout the Gitaly documentation is an arbitrary
 password selected by the administrator. This token is unrelated to tokens
 created for the GitLab API or other similar web API tokens.
@@ -1298,7 +1298,7 @@ nodes (including the Gitaly node using the certificate) and on all client nodes
 that communicate with it following the procedure described in
 [GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
 
-NOTE: **Note:**
+NOTE:
 The self-signed certificate must specify the address you use to access the
 Gitaly server. If you are addressing the Gitaly server by a hostname, you can
 either use the Common Name field for this, or add it as a Subject Alternative

doc/administration/reference_architectures/50k_users.md

@@ -316,7 +316,7 @@ The following IPs will be used as an example:
 - `10.6.0.12`: Consul 2
 - `10.6.0.13`: Consul 3
 
-NOTE: **Note:**
+NOTE:
 The configuration processes for the other servers in your reference architecture will
 use the `/etc/gitlab/gitlab-secrets.json` file from your Consul server to connect
 with the other servers.
@@ -1037,7 +1037,7 @@ servers. The following IPs will be used as an example:
 - `10.6.0.72`: Sentinel - Cache 2
 - `10.6.0.73`: Sentinel - Cache 3
 
-NOTE: **Note:**
+NOTE:
 If you're using an external Redis Sentinel instance, be sure to exclude the
 `requirepass` parameter from the Sentinel configuration. This parameter causes
 clients to report `NOAUTH Authentication required.`.
@@ -1301,7 +1301,7 @@ servers. The following IPs will be used as an example:
 - `10.6.0.82`: Sentinel - Queues 2
 - `10.6.0.83`: Sentinel - Queues 3
 
-NOTE: **Note:**
+NOTE:
 If you're using an external Redis Sentinel instance, be sure to exclude the
 `requirepass` parameter from the Sentinel configuration. This parameter causes
 clients to report `NOAUTH Authentication required.`.
@@ -1422,7 +1422,7 @@ To configure the Sentinel Queues server:
 
 ## Configure Gitaly
 
-NOTE: **Note:**
+NOTE:
 [Gitaly Cluster](../gitaly/praefect.md) support
 for the Reference Architectures is being
 worked on as a [collaborative effort](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/1) between the Quality Engineering and Gitaly teams. When this component has been verified
@@ -1456,7 +1456,7 @@ Be sure to note the following items:
   to restrict access to the Gitaly server. Another option is to
   [use TLS](#gitaly-tls-support).
 
-NOTE: **Note:**
+NOTE:
 The token referred to throughout the Gitaly documentation is an arbitrary
 password selected by the administrator. This token is unrelated to tokens
 created for the GitLab API or other similar web API tokens.
@@ -1574,7 +1574,7 @@ nodes (including the Gitaly node using the certificate) and on all client nodes
 that communicate with it following the procedure described in
 [GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
 
-NOTE: **Note:**
+NOTE:
 The self-signed certificate must specify the address you use to access the
 Gitaly server. If you are addressing the Gitaly server by a hostname, you can
 either use the Common Name field for this, or add it as a Subject Alternative

doc/administration/reference_architectures/5k_users.md

@@ -11,7 +11,7 @@ This page describes GitLab reference architecture for up to 5,000 users. For a
 full list of reference architectures, see
 [Available reference architectures](index.md#available-reference-architectures).
 
-NOTE: **Note:**
+NOTE:
 This reference architecture is designed to help your organization achieve a
 highly-available GitLab deployment. If you do not have the expertise or need to
 maintain a highly-available environment, you can have a simpler and less
@@ -501,7 +501,7 @@ servers. The following IPs will be used as an example:
 - `10.6.0.12`: Consul/Sentinel 2
 - `10.6.0.13`: Consul/Sentinel 3
 
-NOTE: **Note:**
+NOTE:
 If you're using an external Redis Sentinel instance, be sure to exclude the
 `requirepass` parameter from the Sentinel configuration. This parameter causes
 clients to report `NOAUTH Authentication required.`.
@@ -1114,7 +1114,7 @@ Refer to your preferred Load Balancer's documentation for further guidance.
 
 ## Configure Gitaly
 
-NOTE: **Note:**
+NOTE:
 [Gitaly Cluster](../gitaly/praefect.md) support
 for the Reference Architectures is being
 worked on as a [collaborative effort](https://gitlab.com/gitlab-org/quality/reference-architectures/-/issues/1) between the Quality Engineering and Gitaly teams. When this component has been verified
@@ -1148,7 +1148,7 @@ Be sure to note the following items:
   to restrict access to the Gitaly server. Another option is to
   [use TLS](#gitaly-tls-support).
 
-NOTE: **Note:**
+NOTE:
 The token referred to throughout the Gitaly documentation is an arbitrary
 password selected by the administrator. This token is unrelated to tokens
 created for the GitLab API or other similar web API tokens.
@@ -1298,7 +1298,7 @@ nodes (including the Gitaly node using the certificate) and on all client nodes
 that communicate with it following the procedure described in
 [GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
 
-NOTE: **Note:**
+NOTE:
 The self-signed certificate must specify the address you use to access the
 Gitaly server. If you are addressing the Gitaly server by a hostname, you can
 either use the Common Name field for this, or add it as a Subject Alternative

doc/administration/reference_architectures/index.md

@@ -47,7 +47,7 @@ When scaling GitLab, there are several factors to consider:
 - A load balancer is added in front to distribute traffic across the application nodes.
 - The application nodes connects to a shared file server and PostgreSQL and Redis services on the backend.
 
-NOTE: **Note:**
+NOTE:
 Depending on your workflow, the following recommended reference architectures
 may need to be adapted accordingly. Your workload is influenced by factors
 including how active your users are, how much automation you use, mirroring,

doc/administration/reply_by_email_postfix_setup.md

@@ -91,7 +91,7 @@ The instructions make the assumption that you will be using the email address `i
    quit
    ```
 
-   NOTE: **Note:**
+   NOTE:
    The `.` is a literal period on its own line.
 
    If you receive an error after entering `rcpt to: incoming@localhost`
@@ -272,7 +272,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
       quit
       ```
 
-      NOTE: **Note:**
+      NOTE:
       The `.` is a literal period on its own line.
 
    1. Check if the `incoming` user received the email:

doc/administration/repository_checks.md

@@ -17,7 +17,7 @@ before the check result is visible on the project admin page. If the
 checks failed you can see their output on in the [`repocheck.log`
 file.](logs.md#repochecklog)
 
-NOTE: **Note:**
+NOTE:
 It is OFF by default because it still causes too many false alarms.
 
 ## Periodic checks

doc/administration/repository_storage_paths.md

@@ -67,7 +67,7 @@ files and add the full paths of the alternative repository storage paths. In
 the example below, we add two more mount points that are named `nfs_1` and `nfs_2`
 respectively.
 
-NOTE: **Note:**
+NOTE:
 This example uses NFS. We do not recommend using EFS for storage as it may impact GitLab's performance. See the [relevant documentation](nfs.md#avoid-using-awss-elastic-file-system-efs) for more details.
 
 **For installations from source**
@@ -89,7 +89,7 @@ This example uses NFS. We do not recommend using EFS for storage as it may impac
 
 1. [Restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
 
-NOTE: **Note:**
+NOTE:
 We plan to replace [`gitlab_shell: repos_path` entry](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/8-9-stable/config/gitlab.yml.example#L457) in `gitlab.yml` with `repositories: storages`. If you
 are upgrading from a version prior to 8.10, make sure to add the configuration
 as described in the step above. After you make the changes and confirm they are

doc/administration/repository_storage_types.md

@@ -28,7 +28,7 @@ Anything discussed below is expected to be part of that folder.
 
 ## Hashed storage
 
-NOTE: **Note:**
+NOTE:
 In GitLab 13.0, hashed storage is enabled by default and the legacy storage is
 deprecated. Support for legacy storage is scheduled to be removed in GitLab 14.0.
 If you haven't migrated yet, check the

doc/administration/server_hooks.md

@@ -85,7 +85,7 @@ configuration:
   - GitLab 13.0 and earlier, this is set in `gitlab-shell/config.yml`.
   - GitLab 13.1 and later, this is set in `gitaly/config.toml` under the `[hooks]` section.
 
-NOTE: **Note:**
+NOTE:
 The `custom_hooks_dir` value in `gitlab-shell/config.yml` is still honored in GitLab 13.1 and later
 if the value in `gitaly/config.toml` is blank or non-existent.
 
@@ -152,7 +152,7 @@ Pre-receive and post-receive server hooks can also access the following Git envi
 | `GIT_PUSH_OPTION_COUNT`            | Number of push options. See [Git `pre-receive` documentation](https://git-scm.com/docs/githooks#pre-receive).                                                          |
 | `GIT_PUSH_OPTION_<i>`              | Value of push options where `i` is from `0` to `GIT_PUSH_OPTION_COUNT - 1`. See [Git `pre-receive` documentation](https://git-scm.com/docs/githooks#pre-receive).      |
 
-NOTE: **Note:**
+NOTE:
 While other environment variables can be passed to server hooks, your application should not rely on
 them as they can change.
 

doc/administration/terraform_state.md

@@ -20,7 +20,7 @@ These locations can be configured using the options described below.
 
 ## Using local storage
 
-NOTE: **Note:**
+NOTE:
 This is the default configuration
 
 To change the location where Terraform state files are stored locally, follow the steps
@@ -91,7 +91,7 @@ See [the available connection settings for different providers](object_storage.m
    }
    ```
 
-   NOTE: **Note:**
+   NOTE:
    If you are using AWS IAM profiles, be sure to omit the AWS access key and secret access key/value pairs.
 
    ```ruby

doc/administration/timezone.md

@@ -20,7 +20,7 @@ To see all available time zones, run `bundle exec rake time:zones:all`.
 
 For Omnibus installations, run `gitlab-rake time:zones:all`.
 
-NOTE: **Note:**
+NOTE:
 This Rake task does not list timezones in TZInfo format required by Omnibus GitLab during a reconfigure: [#27209](https://gitlab.com/gitlab-org/gitlab/-/issues/27209).
 
 ## Changing time zone in Omnibus installations

doc/administration/troubleshooting/postgresql.md

@@ -169,7 +169,5 @@ It may take a little while to respond.
 {"idle_in_transaction_session_timeout"=>"1min"}
 ```
 
-NOTE: **Note:**
-These are Omnibus GitLab settings. If an external database, such as a
-customer's PostgreSQL installation or Amazon RDS is being used, these values
-don't get set, and would have to be set externally.
+NOTE:
+These are Omnibus GitLab settings. If an external database, such as a customer's PostgreSQL installation or Amazon RDS is being used, these values don't get set, and would have to be set externally.

doc/administration/troubleshooting/test_environments.md

@@ -13,7 +13,7 @@ for users with experience with these tools. If you are currently having an issue
 GitLab, you may want to check your [support options](https://about.gitlab.com/support/)
 first, before attempting to use this information.
 
-NOTE: **Note:**
+NOTE:
 This page was initially written for Support Engineers, so some of the links
 are only available internally at GitLab.
 

doc/administration/uploads.md

@@ -44,7 +44,7 @@ stored locally, use the steps in this section based on your installation method:
 
 **In Omnibus GitLab installations:**
 
-NOTE: **Note:**
+NOTE:
 For historical reasons, uploads are stored into a base directory, which by
 default is `uploads/-/system`. It's strongly discouraged to change this
 configuration option for an existing GitLab installation.

doc/administration/wikis/index.md

@@ -30,7 +30,7 @@ This setting is not available through the [Admin Area settings](../../user/admin
 In order to configure this setting, use either the Rails console
 or the [Application settings API](../../api/settings.md).
 
-NOTE: **Note:**
+NOTE:
 The value of the limit **must** be in bytes. The minimum value is 1024 bytes.
 
 #### Through the Rails console

doc/api/README.md

@@ -123,7 +123,7 @@ There are several methods you can use to authenticate with the GitLab API:
 - [Session cookie](#session-cookie)
 - [GitLab CI/CD job token](#gitlab-ci-job-token) **(Specific endpoints only)**
 
-NOTE: **Note:**
+NOTE:
 Project access tokens are supported for self-managed instances on Core and
 higher. They're also supported on GitLab.com Bronze and higher.
 

doc/api/applications.md

@@ -13,7 +13,7 @@ Applications API operates on OAuth applications for:
 - [Using GitLab as an authentication provider](../integration/oauth_provider.md).
 - [Allowing access to GitLab resources on a user's behalf](oauth2.md).
 
-NOTE: **Note:**
+NOTE:
 Only admin users can use the Applications API.
 
 ## Create an application
@@ -82,7 +82,7 @@ Example response:
 ]
 ```
 
-NOTE: **Note:**
+NOTE:
 The `secret` value will not be exposed by this API.
 
 ## Delete an application

doc/api/avatar.md

@@ -18,7 +18,7 @@ If:
   returned.
 - Public visibility is restricted, response is `403 Forbidden` when unauthenticated.
 
-NOTE: **Note:**
+NOTE:
 This endpoint can be accessed without authentication.
 
 ```plaintext

doc/api/award_emoji.md

@@ -176,7 +176,7 @@ Example Response:
 
 Sometimes it's just not meant to be and you'll have to remove the award.
 
-NOTE: **Note:**
+NOTE:
 Only available to administrators or the author of the award.
 
 ```plaintext
@@ -201,7 +201,7 @@ curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://git
 
 Comments (also known as notes) are a sub-resource of issues, merge requests, and snippets.
 
-NOTE: **Note:**
+NOTE:
 The examples below describe working with award emoji on comments for an issue, but can be
 easily adapted for comments on a merge request or on a snippet. Therefore, you have to replace
 `issue_iid` either with `merge_request_iid` or with the `snippet_id`.
@@ -343,7 +343,7 @@ Example response:
 
 Sometimes it's just not meant to be and you'll have to remove the award.
 
-NOTE: **Note:**
+NOTE:
 Only available to administrators or the author of the award.
 
 ```plaintext

doc/api/boards.md

@@ -423,7 +423,7 @@ POST /projects/:id/boards/:board_id/lists
 | `assignee_id` **(PREMIUM)** | integer | no | The ID of a user |
 | `milestone_id` **(PREMIUM)** | integer | no | The ID of a milestone |
 
-NOTE: **Note:**
+NOTE:
 Label, assignee and milestone arguments are mutually exclusive,
 that is, only one of them are accepted in a request.
 Check the [Issue Board docs](../user/project/issue_board.md)

doc/api/branches.md

@@ -16,7 +16,7 @@ See also [Protected branches API](protected_branches.md).
 
 Get a list of repository branches from a project, sorted by name alphabetically.
 
-NOTE: **Note:**
+NOTE:
 This endpoint can be accessed without authentication if the repository is publicly accessible.
 
 ```plaintext
@@ -73,7 +73,7 @@ Example response:
 
 Get a single project repository branch.
 
-NOTE: **Note:**
+NOTE:
 This endpoint can be accessed without authentication if the repository is publicly accessible.
 
 ```plaintext
@@ -189,7 +189,7 @@ Example response:
 
 Delete a branch from the repository.
 
-NOTE: **Note:**
+NOTE:
 In the case of an error, an explanation message is provided.
 
 ```plaintext
@@ -213,7 +213,7 @@ curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://git
 
 Will delete all branches that are merged into the project's default branch.
 
-NOTE: **Note:**
+NOTE:
 [Protected branches](../user/project/protected_branches.md) will not be deleted as part of this operation.
 
 ```plaintext

doc/api/container_registry.md

@@ -313,7 +313,7 @@ You can run this at most once an hour for a given container repository. This
 action doesn't delete blobs. To delete them and recycle disk space,
 [run the garbage collection](https://docs.gitlab.com/omnibus/maintenance/README.html#removing-unused-layers-not-referenced-by-manifests).
 
-NOTE: **Note:**
+NOTE:
 In GitLab 12.4 and later, individual tags are deleted.
 For more details, see the [discussion](https://gitlab.com/gitlab-org/gitlab/-/issues/15737).
 

doc/api/epics.md

@@ -42,7 +42,7 @@ WARNING:
 > `reference` attribute in response is deprecated in favour of `references`.
 > Introduced [GitLab 12.6](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20354)
 
-NOTE: **Note:**
+NOTE:
 > `references.relative` is relative to the group that the epic is being requested. When epic is fetched from its origin group
 > `relative` format would be the same as `short` format and when requested cross groups it is expected to be the same as `full` format.
 
@@ -251,7 +251,7 @@ Example response:
 
 Creates a new epic.
 
-NOTE: **Note:**
+NOTE:
 Starting with GitLab [11.3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/6448), `start_date` and `end_date` should no longer be assigned
 directly, as they now represent composite values. You can configure it via the `*_is_fixed` and
 `*_fixed` fields instead.
@@ -333,7 +333,7 @@ Example response:
 
 Updates an epic.
 
-NOTE: **Note:**
+NOTE:
 Starting with GitLab [11.3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/6448), `start_date` and `end_date` should no longer be assigned
 directly, as they now represent composite values. You can configure it via the `*_is_fixed` and
 `*_fixed` fields instead.

doc/api/events.md

@@ -268,7 +268,7 @@ Example response:
 
 ## List a Project's visible events
 
-NOTE: **Note:**
+NOTE:
 This endpoint has been around longer than the others. Documentation was formerly located in the [Projects API pages](projects.md).
 
 Get a list of visible events for a particular project.

doc/api/feature_flag_user_lists.md

@@ -13,7 +13,7 @@ API for accessing GitLab Feature Flag User Lists.
 
 Users with Developer or higher [permissions](../user/permissions.md) can access the Feature Flag User Lists API.
 
-NOTE: **Note:**
+NOTE:
 `GET` requests return twenty results at a time because the API results
 are [paginated](README.md#pagination). You can change this value.
 

doc/api/geo_nodes.md

@@ -240,7 +240,7 @@ Example response:
 
 Removes the Geo node.
 
-NOTE: **Note:**
+NOTE:
 Only a Geo primary node will accept this request.
 
 ```plaintext
@@ -548,7 +548,8 @@ Example response:
 }
 ```
 
-Note: The `health_status` parameter can only be in an "Healthy" or "Unhealthy" state, while the `health` parameter can be empty, "Healthy", or contain the actual error message.
+NOTE:
+The `health_status` parameter can only be in an "Healthy" or "Unhealthy" state, while the `health` parameter can be empty, "Healthy", or contain the actual error message.
 
 ## Retrieve project sync or verification failures that occurred on the current node
 

doc/api/graphql/audit_report.md

@@ -105,7 +105,7 @@ explorer. GraphiQL explorer is available for:
 
 ![GraphiQL explorer search for boards](img/user_query_example_v13_2.png)
 
-NOTE: **Note:**
+NOTE:
 [The GraphQL API returns a GlobalID, rather than a standard ID.](getting_started.md#queries-and-mutations) It also expects a GlobalID as an input rather than
 a single integer.
 

doc/api/graphql/getting_started.md

@@ -53,7 +53,7 @@ several issues within the project.
 
 Please refer to [running GraphiQL](index.md#graphiql) for more information.
 
-NOTE: **Note:**
+NOTE:
 If you are running GitLab 11.0 to 12.0, enable the `graphql`
 [feature flag](../features.md#set-or-create-a-feature).
 
@@ -64,7 +64,7 @@ The GitLab GraphQL API can be used to perform:
 - Queries for data retrieval.
 - [Mutations](#mutations) for creating, updating, and deleting data.
 
-NOTE: **Note:**
+NOTE:
 In the GitLab GraphQL API, `id` refers to a
 [Global ID](https://graphql.org/learn/global-object-identification/),
 which is an object identifier in the format of `"gid://gitlab/Issue/123"`.

doc/api/group_clusters.md

@@ -248,7 +248,7 @@ Parameters:
 | `platform_kubernetes_attributes[ca_cert]` | string         | no       | TLS certificate. Required if API is using a self-signed TLS certificate.                   |
 | `environment_scope`                       | string         | no       | The associated environment to the cluster **(PREMIUM)**                                    |
 
-NOTE: **Note:**
+NOTE:
 `name`, `api_url`, `ca_cert` and `token` can only be updated if the cluster was added
 through the ["Add existing Kubernetes cluster"](../user/project/clusters/add_remove_clusters.md#add-existing-cluster) option or
 through the ["Add existing cluster to group"](#add-existing-cluster-to-group) endpoint.

doc/api/group_import_export.md

@@ -92,7 +92,7 @@ by `@`. For example:
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" --form "name=imported-group" --form "path=imported-group" --form "file=@/path/to/file" "https://gitlab.example.com/api/v4/groups/import"
 ```
 
-NOTE: **Note:**
+NOTE:
 The maximum import file size can be set by the Administrator, default is 50MB.
 As an administrator, you can modify the maximum import file size. To do so, use the `max_import_size` option in the [Application settings API](settings.md#change-application-settings) or the [Admin UI](../user/admin_area/settings/account_and_limit_settings.md).
 

doc/api/group_labels.md

@@ -10,7 +10,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 This API supports managing of [group labels](../user/project/labels.md#project-labels-and-group-labels). It allows to list, create, update, and delete group labels. Furthermore, users can subscribe and unsubscribe to and from group labels.
 
-NOTE: **Note:**
+NOTE:
 The `description_html` - was added to response JSON in [GitLab 12.7](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/21413).
 
 ## List group labels
@@ -175,7 +175,7 @@ Example response:
 }
 ```
 
-NOTE: **Note:**
+NOTE:
 An older endpoint `PUT /groups/:id/labels` with `name` in the parameters is still available, but deprecated.
 
 ## Delete a group label
@@ -195,7 +195,7 @@ DELETE /groups/:id/labels/:label_id
 curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/groups/5/labels/bug"
 ```
 
-NOTE: **Note:**
+NOTE:
 An older endpoint `DELETE /groups/:id/labels` with `name` in the parameters is still available, but deprecated.
 
 ## Subscribe to a group label

doc/api/groups.md

@@ -338,7 +338,7 @@ Example response:
 ]
 ```
 
-NOTE: **Note:**
+NOTE:
 To distinguish between a project in the group and a project shared to the group, the `namespace` attribute can be used. When a project has been shared to the group, its `namespace` differs from the group the request is being made for.
 
 ## List a group's shared projects
@@ -493,7 +493,7 @@ Parameters:
 | `with_custom_attributes` | boolean        | no       | Include [custom attributes](custom_attributes.md) in response (admins only). |
 | `with_projects`          | boolean        | no       | Include details from projects that belong to the specified group (defaults to `true`). (Deprecated, [scheduled for removal in API v5](https://gitlab.com/gitlab-org/gitlab/-/issues/213797). To get the details of all projects within a group, use the [list a group's projects endpoint](#list-a-groups-projects).)  |
 
-NOTE: **Note:**
+NOTE:
 The `projects` and `shared_projects` attributes in the response are deprecated and [scheduled for removal in API v5](https://gitlab.com/gitlab-org/gitlab/-/issues/213797).
 To get the details of all projects within a group, use either the [list a group's projects](#list-a-groups-projects) or the [list a group's shared projects](#list-a-groups-shared-projects) endpoint.
 
@@ -853,7 +853,7 @@ PUT /groups/:id
 | `extra_shared_runners_minutes_limit` | integer | no       | **(STARTER ONLY)** Extra pipeline minutes quota for this group (purchased in addition to the minutes included in the plan). |
 | `prevent_forking_outside_group`      | boolean | no       | **(PREMIUM)** When enabled, users can **not** fork projects from this group to external namespaces
 
-NOTE: **Note:**
+NOTE:
 The `projects` and `shared_projects` attributes in the response are deprecated and [scheduled for removal in API v5](https://gitlab.com/gitlab-org/gitlab/-/issues/213797).
 To get the details of all projects within a group, use either the [list a group's projects](#list-a-groups-projects) or the [list a group's shared projects](#list-a-groups-shared-projects) endpoint.
 
@@ -1170,7 +1170,7 @@ POST /groups/:id/ldap_group_links
 | `group_access` | integer   | yes      | Minimum [access level](members.md#valid-access-levels) for members of the LDAP group |
 | `provider` | string        | yes      | LDAP provider for the LDAP group link |
 
-NOTE: **Note:**
+NOTE:
 To define the LDAP group link, provide either a `cn` or a `filter`, but not both.
 
 ### Delete LDAP group link **(STARTER ONLY)**
@@ -1213,7 +1213,7 @@ DELETE /groups/:id/ldap_group_links
 | `filter`  | string         | no       | The LDAP filter for the group |
 | `provider` | string        | yes       | LDAP provider for the LDAP group link |
 
-NOTE: **Note:**
+NOTE:
 To delete the LDAP group link, provide either a `cn` or a `filter`, but not both.
 
 ## Namespaces in groups

doc/api/import.md

@@ -50,7 +50,7 @@ Example response:
 
 Import your projects from Bitbucket Server to GitLab via the API.
 
-NOTE: **Note:**
+NOTE:
 The Bitbucket Project Key is only used for finding the repository in Bitbucket.
 You must specify a `target_namespace` if you want to import the repository to a GitLab group.
 If you do not specify `target_namespace`, the project imports to your personal user namespace.

doc/api/instance_clusters.md

@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36001) in GitLab 13.2.
 
-NOTE: **Note:**
+NOTE:
 Users need admin access to use these endpoints.
 
 Use these API endpoints with your instance clusters, which enable you to use the same cluster across multiple projects. [More information](../user/instance/clusters/index.md)
@@ -238,7 +238,7 @@ Parameters:
 | `platform_kubernetes_attributes[ca_cert]`   | string  | no       | TLS certificate. Required if API is using a self-signed TLS certificate.                   |
 | `platform_kubernetes_attributes[namespace]` | string  | no       | The unique namespace related to the project                                                |
 
-NOTE: **Note:**
+NOTE:
 `name`, `api_url`, `ca_cert` and `token` can only be updated if the cluster was added
 through the [Add existing Kubernetes cluster](../user/project/clusters/add_remove_clusters.md#add-existing-cluster) option or
 through the [Add existing instance cluster](#add-existing-instance-cluster) endpoint.

doc/api/issues.md

@@ -20,7 +20,7 @@ DANGER: **Deprecated:**
 The `reference` attribute in responses is deprecated in favor of `references`.
 Introduced in [GitLab 12.6](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20354).
 
-NOTE: **Note:**
+NOTE:
 The `references.relative` attribute is relative to the group or project of the issue being requested.
 When an issue is fetched from its project, the `relative` format is the same as the `short` format,
 and when requested across groups or projects it's expected to be the same as the `full` format.
@@ -201,7 +201,7 @@ DANGER: **Deprecated:**
 The `assignee` column is deprecated. We now show it as a single-sized array `assignees` to conform
 to the GitLab EE API.
 
-NOTE: **Note:**
+NOTE:
 The `closed_by` attribute was [introduced in GitLab 10.6](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17042).
 This value is only present for issues closed after GitLab 10.6 and if the user account
 that closed the issue still exists.
@@ -378,7 +378,7 @@ the `health_status` parameter:
 DANGER: **Deprecated:**
 The `assignee` column is deprecated. We now show it as a single-sized array `assignees` to conform to the GitLab EE API.
 
-NOTE: **Note:**
+NOTE:
 The `closed_by` attribute was [introduced in GitLab 10.6](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17042).
 This value is only present for issues closed after GitLab 10.6 and if the user account that closed
 the issue still exists.
@@ -561,7 +561,7 @@ the `health_status` parameter:
 DANGER: **Deprecated:**
 The `assignee` column is deprecated. We now show it as a single-sized array `assignees` to conform to the GitLab EE API.
 
-NOTE: **Note:**
+NOTE:
 The `closed_by` attribute was [introduced in GitLab 10.6](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17042). This value is only present for issues closed after GitLab 10.6 and if the user account that closed
 the issue still exists.
 
@@ -724,7 +724,7 @@ DANGER: **Deprecated:**
 The `epic_iid` attribute is deprecated, and [will be removed in version 5](https://gitlab.com/gitlab-org/gitlab/-/issues/35157).
 Please use `iid` of the `epic` attribute instead.
 
-NOTE: **Note:**
+NOTE:
 The `closed_by` attribute was [introduced in GitLab 10.6](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17042).
 This value is only present for issues closed after GitLab 10.6 and if the user account
 that closed the issue still exists.
@@ -885,7 +885,7 @@ DANGER: **Deprecated:**
 The `epic_iid` attribute is deprecated and [will be removed in version 5](https://gitlab.com/gitlab-org/gitlab/-/issues/35157).
 Please use `iid` of the `epic` attribute instead.
 
-NOTE: **Note:**
+NOTE:
 The `closed_by` attribute was [introduced in GitLab 10.6](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17042). This value is only present for issues closed after GitLab 10.6 and if the user account that closed
 the issue still exists.
 
@@ -1009,7 +1009,7 @@ the `health_status` parameter:
 DANGER: **Deprecated:**
 The `assignee` column is deprecated. We now show it as a single-sized array `assignees` to conform to the GitLab EE API.
 
-NOTE: **Note:**
+NOTE:
 The `closed_by` attribute was [introduced in GitLab 10.6](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17042). This value is only present for issues closed after GitLab 10.6 and if the user account that closed
 the issue still exists.
 
@@ -1159,7 +1159,7 @@ the `health_status` parameter:
 ]
 ```
 
-NOTE: **Note:**
+NOTE:
 The `closed_by` attribute was [introduced in GitLab 10.6](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17042). This value is only present for issues closed after GitLab 10.6 and if the user account that closed
 the issue still exists.
 
@@ -1327,7 +1327,7 @@ the `health_status` parameter:
 DANGER: **Deprecated:**
 The `assignee` column is deprecated. We now show it as a single-sized array `assignees` to conform to the GitLab EE API.
 
-NOTE: **Note:**
+NOTE:
 The `closed_by` attribute was [introduced in GitLab 10.6](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17042). This value is only present for issues closed after GitLab 10.6 and if the user account that closed
 the issue still exists.
 
@@ -1436,7 +1436,7 @@ the `weight` parameter:
 DANGER: **Deprecated:**
 The `assignee` column is deprecated. We now show it as a single-sized array `assignees` to conform to the GitLab EE API.
 
-NOTE: **Note:**
+NOTE:
 The `closed_by` attribute was [introduced in GitLab 10.6](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17042). This value is only present for issues closed after GitLab 10.6 and if the user account that closed
 the issue still exists.
 
@@ -1626,7 +1626,7 @@ Example response:
 DANGER: **Deprecated:**
 The `assignee` column is deprecated. We now show it as a single-sized array `assignees` to conform to the GitLab EE API.
 
-NOTE: **Note:**
+NOTE:
 The `closed_by` attribute was [introduced in GitLab 10.6](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17042). This value is only present for issues closed after GitLab 10.6 and if the user account that closed
 the issue still exists.
 

doc/api/job_artifacts.md

@@ -69,7 +69,7 @@ the given reference name and job, provided the job finished successfully. This
 is the same as [getting the job's artifacts](#get-job-artifacts), but by
 defining the job's name instead of its ID.
 
-NOTE: **Note:**
+NOTE:
 If a pipeline is [parent of other child pipelines](../ci/parent_child_pipelines.md), artifacts
 are searched in hierarchical order from parent to child. For example, if both parent and
 child pipelines have a job with the same name, the artifact from the parent pipeline is returned.
@@ -275,7 +275,7 @@ Example request:
 curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/jobs/1/artifacts"
 ```
 
-NOTE: **Note:**
+NOTE:
 At least Maintainer role is required to delete artifacts.
 
 If the artifacts were deleted successfully, a response with status `204 No Content` is returned.

doc/api/labels.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Labels API
 
-NOTE: **Note:**
+NOTE:
 The `description_html` - was added to response JSON in [GitLab 12.7](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/21413).
 
 ## List labels
@@ -200,7 +200,7 @@ DELETE /projects/:id/labels/:label_id
 curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/1/labels/bug"
 ```
 
-NOTE: **Note:**
+NOTE:
 An older endpoint `DELETE /projects/:id/labels` with `name` in the parameters is still available, but deprecated.
 
 ## Edit an existing label
@@ -244,7 +244,7 @@ Example response:
 }
 ```
 
-NOTE: **Note:**
+NOTE:
 An older endpoint `PUT /projects/:id/labels` with `name` or `label_id` in the parameters is still available, but deprecated.
 
 ## Promote a project label to a group label
@@ -285,7 +285,7 @@ Example response:
 }
 ```
 
-NOTE: **Note:**
+NOTE:
 An older endpoint `PUT /projects/:id/labels/promote` with `name` in the parameters is still available, but deprecated.
 
 ## Subscribe to a label

doc/api/merge_request_approvals.md

@@ -499,7 +499,7 @@ DELETE /projects/:id/approval_rules/:approval_rule_id
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/183) in [GitLab Starter](https://about.gitlab.com/pricing/) 10.6.
 
-NOTE: **Note:**
+NOTE:
 This API endpoint has been deprecated. Please use Approval Rule API instead.
 
 If you are allowed to, you can change approvers and approver groups using
@@ -650,7 +650,7 @@ POST /projects/:id/merge_requests/:merge_request_iid/approvals
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/183) in [GitLab Starter](https://about.gitlab.com/pricing/) 10.6.
 
-NOTE: **Note:**
+NOTE:
 This API endpoint has been deprecated. Please use Approval Rule API instead.
 
 If you are allowed to, you can change approvers and approver groups using

doc/api/merge_requests.md

@@ -13,7 +13,7 @@ WARNING:
 > `reference` attribute in response is deprecated in favour of `references`.
 > Introduced [GitLab 12.6](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20354)
 
-NOTE: **Note:**
+NOTE:
 > `references.relative` is relative to the group / project that the merge request is being requested. When merge request is fetched from its project
 > `relative` format would be the same as `short` format and when requested across groups / projects it is expected to be the same as `full` format.
 
@@ -76,14 +76,14 @@ Parameters:
 | `deployed_before`               | datetime       | no       | Return merge requests deployed before the given date/time. Expected in ISO 8601 format (`2019-03-15T08:00:00Z`) |
 | `deployed_after`                | datetime       | no       | Return merge requests deployed after the given date/time. Expected in ISO 8601 format (`2019-03-15T08:00:00Z`) |
 
-NOTE: **Note:**
+NOTE:
 [Starting in GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/31890),
 listing merge requests may not proactively update the `merge_status` field
 (which also affects the `has_conflicts` field), as this can be an expensive
 operation. If you are interested in the value of these fields from this
 endpoint, set the `with_merge_status_recheck` parameter to `true` in the query.
 
-NOTE: **Note:**
+NOTE:
 [Starting in GitLab 12.8](https://gitlab.com/gitlab-org/gitlab/-/issues/29984),
 the mergeability (`merge_status`) of each merge request will be checked
 asynchronously when a request is made to this endpoint. Poll this API endpoint
@@ -563,7 +563,7 @@ Parameters:
 - `include_diverged_commits_count` (optional) - If `true` response includes the commits behind the target branch
 - `include_rebase_in_progress` (optional) - If `true` response includes whether a rebase operation is in progress
 
-NOTE: **Note:**
+NOTE:
 [Starting in GitLab 12.8](https://gitlab.com/gitlab-org/gitlab/-/issues/29984),
 the mergeability (`merge_status`) of a merge request will be checked
 asynchronously when a request is made to this endpoint. Poll this API endpoint

doc/api/namespaces.md

@@ -113,7 +113,7 @@ once a day.
 ]
 ```
 
-NOTE: **Note:**
+NOTE:
 Only group maintainers/owners are presented with `members_count_with_descendants`, as well as `plan` **(BRONZE ONLY)**.
 
 ## Search for namespace

doc/api/oauth2.md

@@ -59,7 +59,7 @@ authorization with each flow.
 
 ### Web application flow
 
-NOTE: **Note:**
+NOTE:
 Check the [RFC spec](https://tools.ietf.org/html/rfc6749#section-4.1) for a
 detailed flow description.
 
@@ -105,7 +105,7 @@ The web application flow is:
    }
    ```
 
-NOTE: **Note:**
+NOTE:
 The `redirect_uri` must match the `redirect_uri` used in the original
 authorization request.
 
@@ -113,7 +113,7 @@ You can now make requests to the API with the access token returned.
 
 ### Implicit grant flow
 
-NOTE: **Note:**
+NOTE:
 Check the [RFC spec](https://tools.ietf.org/html/rfc6749#section-4.2) for a
 detailed flow description.
 
@@ -149,11 +149,11 @@ https://example.com/oauth/redirect#access_token=ABCDExyz123&state=YOUR_UNIQUE_ST
 
 ### Resource owner password credentials flow
 
-NOTE: **Note:**
+NOTE:
 Check the [RFC spec](https://tools.ietf.org/html/rfc6749#section-4.3) for a
 detailed flow description.
 
-NOTE: **Note:**
+NOTE:
 The Resource Owner Password Credentials is disabled for users with [two-factor
 authentication](../user/profile/account/two_factor_authentication.md) turned on.
 These users can access the API using [personal access tokens](../user/profile/personal_access_tokens.md)

doc/api/personal_access_tokens.md

@@ -23,7 +23,7 @@ GET /personal_access_tokens
 |-----------|---------|----------|---------------------|
 | `user_id` | integer/string | no | The ID of the user to filter by |
 
-NOTE: **Note:**
+NOTE:
 Administrators can use the `user_id` parameter to filter by a user. Non-administrators cannot filter by any user except themselves. Attempting to do so will result in a `401 Unauthorized` response.
 
 ```shell
@@ -82,7 +82,7 @@ DELETE /personal_access_tokens/:id
 |-----------|---------|----------|---------------------|
 | `id` | integer/string | yes | ID of personal access token |
 
-NOTE: **Note:**
+NOTE:
 Non-administrators can revoke their own tokens. Administrators can revoke tokens of any user.
 
 ```shell