Add latest changes from gitlab-org/gitlab@master

11 files changed, 203 insertions, 62 deletions

diff --git a/doc/.vale/gitlab/spelling-exceptions.txt b/doc/.vale/gitlab/spelling-exceptions.txt
index b855a3b9bbd..f9db0f99973 100644
--- a/doc/.vale/gitlab/spelling-exceptions.txt
+++ b/doc/.vale/gitlab/spelling-exceptions.txt
@@ -19,6 +19,7 @@ architected
 architecting
 archiver
 Arel
+arity
 Artifactory
 Asana
 Asciidoctor
diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index 08c6a05ca99..e072696b37c 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -320,7 +320,7 @@ sudo gitlab-ctl \
    --backup-timeout=21600
 ```
 
-This will give the initial replication up to six hours to complete, rather than
+This gives the initial replication up to six hours to complete, rather than
 the default thirty minutes. Adjust as required for your installation.
 
 ### Message: "PANIC: could not write to file `pg_xlog/xlogtemp.123`: No space left on device"
@@ -335,7 +335,7 @@ log data to build up in `pg_xlog`. Removing the unused slots can reduce the amou
    ```
 
    NOTE:
-   Using `gitlab-rails dbconsole` will not work, because managing replication slots requires superuser permissions.
+   Using `gitlab-rails dbconsole` does not work, because managing replication slots requires superuser permissions.
 
 1. View your replication slots with:
 
@@ -358,13 +358,12 @@ Slots where `active` is `f` are not active.
 
 ### Message: "ERROR: canceling statement due to conflict with recovery"
 
-This error may rarely occur under normal usage, and the system is resilient
+This error occurs infrequently under normal usage, and the system is resilient
 enough to recover.
 
 However, under certain conditions, some database queries on secondaries may run
-excessively long, which increases the frequency of this error. At some point,
-some of these queries will never be able to complete due to being canceled
-every time.
+excessively long, which increases the frequency of this error. This can lead to a situation
+where some queries never complete due to being canceled on every replication.
 
 These long-running queries are
 [planned to be removed in the future](https://gitlab.com/gitlab-org/gitlab/-/issues/34269),
@@ -505,7 +504,7 @@ Then reconfigure GitLab:
 sudo gitlab-ctl reconfigure
 ```
 
-This will increase the timeout to four hours (14400 seconds). Choose a time
+This increases the timeout to four hours (14400 seconds). Choose a time
 long enough to accommodate a full clone of your largest repositories.
 
 ### New LFS objects are never replicated
@@ -564,9 +563,8 @@ to start again from scratch, there are a few steps that can help you:
 1. _(Optional)_ Rename other data folders and create new ones
 
    WARNING:
-   You may still have files on the **secondary** node that have been removed from **primary** node but
-   removal have not been reflected. If you skip this step, they will never be removed
-   from this Geo node.
+   You may still have files on the **secondary** node that have been removed from the **primary** node, but this
+   removal has not been reflected. If you skip this step, these files are not removed at all from the Geo node.
 
    Any uploaded content like file attachments, avatars or LFS objects are stored in a
    subfolder in one of the two paths below:
@@ -661,12 +659,12 @@ Counts:
 
 #### If you are promoting a Geo secondary site running on a single server
 
-`gitlab-ctl promotion-preflight-checks` will fail due to the existence of
+`gitlab-ctl promotion-preflight-checks` fails due to the existence of
 `failed` rows in the `geo_design_registry` table. Use the
 [previous snippet](#design-repository-failures-on-mirrored-projects-and-project-imports) to
 determine the actual replication status of Design repositories.
 
-`gitlab-ctl promote-to-primary-node` will fail since it runs preflight checks.
+`gitlab-ctl promote-to-primary-node` fails since it runs preflight checks.
 If the [previous snippet](#design-repository-failures-on-mirrored-projects-and-project-imports)
 shows that all designs are synced, then you can use the
 `--skip-preflight-checks` option or the `--force` option to move forward with
@@ -674,7 +672,7 @@ promotion.
 
 #### If you are promoting a Geo secondary site running on multiple servers
 
-`gitlab-ctl promotion-preflight-checks` will fail due to the existence of
+`gitlab-ctl promotion-preflight-checks` fails due to the existence of
 `failed` rows in the `geo_design_registry` table. Use the
 [previous snippet](#design-repository-failures-on-mirrored-projects-and-project-imports) to
 determine the actual replication status of Design repositories.
@@ -766,7 +764,7 @@ When
 you need to run the `gitlab-pg-ctl` command to promote the PostgreSQL
 read-replica database.
 
-In GitLab 12.8 and earlier, this command will fail with the message:
+In GitLab 12.8 and earlier, this command fails with the message:
 
 ```plaintext
 sudo: gitlab-pg-ctl: command not found
@@ -825,7 +823,7 @@ If you notice for some reason there are more artifacts on the Geo
 secondary node than on the Geo primary node, you can use the Rake task
 to [cleanup orphan artifact files](../../../raketasks/cleanup.md#remove-orphan-artifact-files).
 
-On a Geo **secondary** node, this command will also clean up all Geo
+On a Geo **secondary** node, this command also cleans up all Geo
 registry record related to the orphan files on disk.
 
 ## Fixing sign in errors
diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index 694e17bb147..eb118709f94 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -824,6 +824,13 @@ notifications:
 
 ## Run the Cleanup policy now
 
+WARNING:
+If you're using a distributed architecture and Sidekiq is running on a different node, the cleanup
+policies don't work. To fix this, you must configure the `gitlab.rb` file on the Sidekiq nodes to
+point to the correct registry URL and copy the `registry.key` file to each Sidekiq node. For more
+information, see the [Sidekiq configuration](../sidekiq.md)
+page.
+
 To reduce the amount of [Container Registry disk space used by a given project](../troubleshooting/gitlab_rails_cheat_sheet.md#registry-disk-space-usage-by-project),
 administrators can clean up image tags
 and [run garbage collection](#container-registry-garbage-collection).
diff --git a/doc/administration/sidekiq.md b/doc/administration/sidekiq.md
index 95fef1255af..e753832f2c3 100644
--- a/doc/administration/sidekiq.md
+++ b/doc/administration/sidekiq.md
@@ -94,6 +94,16 @@ you want using steps 1 and 2 from the GitLab downloads page.
    gitlab_exporter['enable'] = false
    ```
 
+1. If you're using the Container Registry and it's running on a different node than Sidekiq, then
+   configure the registry URL:
+
+   ```ruby
+   registry_external_url 'https://registry.example.com'
+   gitlab_rails['registry_api_url'] = "https://registry.example.com"
+   ```
+  
+   You must also copy the `registry.key` file to each Sidekiq node.
+
 1. Run `gitlab-ctl reconfigure`.
 
 You will need to restart the Sidekiq nodes after an update has occurred and database
@@ -180,6 +190,10 @@ node_exporter['listen_address'] = '10.10.1.48:9100'
 
 # Rails Status for prometheus
 gitlab_rails['monitoring_whitelist'] = ['10.10.1.42', '127.0.0.1']
+
+# Container Registry URL for cleanup jobs
+registry_external_url 'https://registry.example.com'
+gitlab_rails['registry_api_url'] = "https://registry.example.com"
 ```
 
 ## Further reading
diff --git a/doc/ci/pipelines/index.md b/doc/ci/pipelines/index.md
index f3d4cb72e62..0ccbac2ab2d 100644
--- a/doc/ci/pipelines/index.md
+++ b/doc/ci/pipelines/index.md
@@ -363,9 +363,7 @@ you visualize the entire pipeline, including all cross-project inter-dependencie
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/298973) in GitLab 13.12.
 > - [Deployed behind a feature flag](../../user/feature_flags.md), disabled by default.
 > - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/328538) in GitLab 13.12.
-> - Enabled on GitLab.com.
-> - Recommended for production use.
-> - To disable in GitLab self-managed instances, ask a GitLab administrator to [disable it](#enable-or-disable-job-dependency-view). **(FREE SELF)**
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/328538) in GitLab 14.2.
 
 This in-development feature might not be available for your use. There can be
 [risks when enabling features still in development](../../administration/feature_flags.md#risks-when-enabling-features-still-in-development).
@@ -391,24 +389,6 @@ To see the full `needs` dependency tree for a job, hover over it:
 
 ![single job dependency tree highlighted](img/pipelines_graph_dependency_view_hover_v13_12.png)
 
-#### Enable or disable job dependency view **(FREE SELF)**
-
-The job dependency view is deployed behind a feature flag that is **enabled by default**.
-[GitLab administrators with access to the GitLab Rails console](../../administration/feature_flags.md)
-can disable it.
-
-To enable it:
-
-```ruby
-Feature.enable(:pipeline_graph_layers_view)
-```
-
-To disable it:
-
-```ruby
-Feature.disable(:pipeline_graph_layers_view)
-```
-
 ### Pipeline mini graphs
 
 Pipeline mini graphs take less space and can tell you at a
diff --git a/doc/ci/review_apps/index.md b/doc/ci/review_apps/index.md
index cf43d96c2d1..8af04388f92 100644
--- a/doc/ci/review_apps/index.md
+++ b/doc/ci/review_apps/index.md
@@ -41,13 +41,13 @@ The following is an example of a merge request with an environment set dynamical
 In this example, a branch was:
 
 - Successfully built.
-- Deployed under a dynamic environment that can be reached by clicking on the **View app** button.
+- Deployed under a dynamic environment that can be reached by selecting **View app**.
 
 After adding Review Apps to your workflow, you follow the branched Git flow. That is:
 
 1. Push a branch and let the runner deploy the Review App based on the `script` definition of the dynamic environment job.
 1. Wait for the runner to build and deploy your web application.
-1. Click on the link provided in the merge request related to the branch to see the changes live.
+1. To view the changes live, select the link in the merge request related to the branch.
 
 ## Configuring Review Apps
 
@@ -66,21 +66,26 @@ The process of configuring Review Apps is as follows:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/118844) in GitLab 12.8.
 
-When configuring Review Apps for a project, you need to add a new job to `.gitlab-ci.yml`,
-as mentioned above. To facilitate this and if you are using Kubernetes, you can click
-the **Enable Review Apps** button and GitLab prompts you with a template code block that
-you can copy and paste into `.gitlab-ci.yml` as a starting point. To do so:
+When configuring Review Apps for a project, you add a new job to the `.gitlab-ci.yml` file,
+as mentioned above. To facilitate this, and if you are using Kubernetes, you can select
+**Enable Review Apps** and GitLab prompts you with a template code block that
+you can copy and paste into `.gitlab-ci.yml` as a starting point.
 
-1. Go to the project your want to create a Review App job for.
-1. From the left nav, go to **Deployments > Environments**.
-1. Click on the **Enable Review Apps** button. It is available to you
-   if you have Developer or higher [permissions](../../user/permissions.md) to that project.
+Prerequisite:
+
+- You need at least the Developer [role](../../user/permissions.md) for the project.
+
+To use the Review Apps template:
+
+1. On the top bar, select **Menu > Projects** and find the project you want to create a Review App job for.
+1. On the left sidebar, select **Deployments > Environments**.
+1. Select **Enable Review Apps**.
 1. Copy the provided code snippet and paste it into your
    `.gitlab-ci.yml` file:
 
    ![Enable Review Apps modal](img/enable_review_app_v12_8.png)
 
-1. Feel free to tune this template to your own needs.
+You can edit this template as needed.
 
 ## Review Apps auto-stop
 
@@ -168,9 +173,9 @@ and results in a public path of `index.html`, instead of
 
 After you have the route mapping set up, it takes effect in the following locations:
 
-- In the merge request widget. The:
-  - **View app** button takes you to the environment URL set in `.gitlab-ci.yml`.
-  - Dropdown lists the first 5 matched items from the route map, but you can filter them if more
+- In the merge request widget:
+  - The **View app** button takes you to the environment URL set in the `.gitlab-ci.yml` file.
+  - The list shows the first 5 matched items from the route map, but you can filter them if more
     than 5 are available.
 
     ![View app file list in merge request widget](img/view_on_mr_widget.png)
@@ -202,14 +207,14 @@ Review App, the Visual Reviews feedback form is overlaid on the right side of ev
 
 To use the feedback form to make a comment in the merge request:
 
-1. Click the **Review** tab on the right side of a page.
+1. On the right side of a page, select the **Review** tab.
 1. Make a comment on the visual review. You can make use of all the
    [Markdown annotations](../../user/markdown.md) that are also available in
    merge request comments.
 1. Enter your personal information:
    - If [`data-require-auth`](#authentication-for-visual-reviews) is `true`, you must enter your [personal access token](../../user/profile/personal_access_tokens.md).
    - Otherwise, enter your name, and optionally your email.
-1. Click **Send feedback**.
+1. Select **Send feedback**.
 
 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
 To see Visual reviews in action, see the [Visual Reviews Walk through](https://youtu.be/1_tvWTlPfM4).
diff --git a/doc/development/documentation/site_architecture/index.md b/doc/development/documentation/site_architecture/index.md
index 9ee56a6d517..046de5c6d86 100644
--- a/doc/development/documentation/site_architecture/index.md
+++ b/doc/development/documentation/site_architecture/index.md
@@ -60,7 +60,7 @@ as such the docs for CE and EE are now identical. For historical reasons and
 in order not to break any existing links throughout the internet, we still
 maintain the CE docs (`https://docs.gitlab.com/ce/`), although it is hidden
 from the website, and is now a symlink to the EE docs. When
-[Pages supports redirects](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/24),
+[Support wildcard redirects](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/500) is resolved,
 we can remove this completely.
 
 ## Assets
diff --git a/doc/development/testing_guide/testing_migrations_guide.md b/doc/development/testing_guide/testing_migrations_guide.md
index d54ca0d3c64..757a70fb4e0 100644
--- a/doc/development/testing_guide/testing_migrations_guide.md
+++ b/doc/development/testing_guide/testing_migrations_guide.md
@@ -127,7 +127,90 @@ reversible_migration do |migration|
 end
 ```
 
-### Example database migration test
+### Custom matchers for post-deployment migrations
+
+We have some custom matchers in
+[`spec/support/matchers/background_migrations_matchers.rb`](https://gitlab.com/gitlab-org/gitlab/blob/v14.1.0-ee/spec/support/matchers/background_migrations_matchers.rb)
+to verify background migrations were correctly scheduled from a post-deployment migration, and
+receive the correct number of arguments.
+
+All of them use the internal matcher `be_background_migration_with_arguments`, which verifies that
+the `#perform` method on your migration class doesn't crash when receiving the provided arguments.
+
+#### `be_scheduled_migration`
+
+Verifies that a Sidekiq job was queued with the expected class and arguments.
+
+This matcher usually makes sense if you're queueing jobs manually, rather than going through our helpers.
+
+```ruby
+# Migration
+BackgroundMigrationWorker.perform_async('MigrationClass', args)
+
+# Spec
+expect('MigrationClass').to be_scheduled_migration(*args)
+```
+
+#### `be_scheduled_migration_with_multiple_args`
+
+Verifies that a Sidekiq job was queued with the expected class and arguments.
+
+This works the same as `be_scheduled_migration`, except that the order is ignored when comparing
+array arguments.
+
+```ruby
+# Migration
+BackgroundMigrationWorker.perform_async('MigrationClass', ['foo', [3, 2, 1]])
+
+# Spec
+expect('MigrationClass').to be_scheduled_migration_with_multiple_args('foo', [1, 2, 3])
+```
+
+#### `be_scheduled_delayed_migration`
+
+Verifies that a Sidekiq job was queued with the expected delay, class, and arguments.
+
+This can also be used with `queue_background_migration_jobs_by_range_at_intervals` and related helpers.
+
+```ruby
+# Migration
+BackgroundMigrationWorker.perform_in(delay, 'MigrationClass', args)
+
+# Spec
+expect('MigrationClass').to be_scheduled_delayed_migration(delay, *args)
+```
+
+#### `have_scheduled_batched_migration`
+
+Verifies that a `BatchedMigration` record was created with the expected class and arguments.
+
+The `*args` are additional arguments passed to the `MigrationClass`, while `**kwargs` are any other
+attributes to be verified on the `BatchedMigration` record (Example: `interval: 2.minutes`).
+
+```ruby
+# Migration
+queue_batched_background_migration(
+  'MigrationClass',
+  table_name,
+  column_name,
+  *args,
+  **kwargs
+)
+
+# Spec
+expect('MigrationClass').to have_scheduled_batched_migration(
+  table_name: table_name,
+  column_name: column_name,
+  job_arguments: args,
+  **kwargs
+)
+```
+
+### Examples of migration tests
+
+Migration tests depend on what the migration does exactly, the most common types are data migrations and scheduling background migrations.
+
+#### Example of a data migration test
 
 This spec tests the
 [`db/post_migrate/20170526185842_migrate_pipeline_stages.rb`](https://gitlab.com/gitlab-org/gitlab-foss/blob/v11.6.5/db/post_migrate/20170526185842_migrate_pipeline_stages.rb)
@@ -181,6 +264,59 @@ RSpec.describe MigratePipelineStages do
 end
 ```
 
+#### Example of a background migration scheduling test
+
+To test these you usually have to:
+
+- Create some records.
+- Run the migration.
+- Verify that the expected jobs were scheduled, with the correct set
+  of records, the correct batch size, interval, etc.
+
+The behavior of the background migration itself needs to be verified in a [separate
+test for the background migration class](#example-background-migration-test).
+
+This spec tests the
+[`db/post_migrate/20210701111909_backfill_issues_upvotes_count.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/v14.1.0-ee/db/post_migrate/20210701111909_backfill_issues_upvotes_count.rb)
+post-deployment migration. You can find the complete spec in
+[`spec/migrations/backfill_issues_upvotes_count_spec.rb`](https://gitlab.com/gitlab-org/gitlab/blob/v14.1.0-ee/spec/spec/migrations/backfill_issues_upvotes_count_spec.rb).
+
+```ruby
+require 'spec_helper'
+require_migration!
+
+RSpec.describe BackfillIssuesUpvotesCount do
+  let(:migration) { described_class.new }
+  let(:issues) { table(:issues) }
+  let(:award_emoji) { table(:award_emoji) }
+
+  let!(:issue1) { issues.create! }
+  let!(:issue2) { issues.create! }
+  let!(:issue3) { issues.create! }
+  let!(:issue4) { issues.create! }
+  let!(:issue4_without_thumbsup) { issues.create! }
+
+  let!(:award_emoji1) { award_emoji.create!( name: 'thumbsup', awardable_type: 'Issue', awardable_id: issue1.id) }
+  let!(:award_emoji2) { award_emoji.create!( name: 'thumbsup', awardable_type: 'Issue', awardable_id: issue2.id) }
+  let!(:award_emoji3) { award_emoji.create!( name: 'thumbsup', awardable_type: 'Issue', awardable_id: issue3.id) }
+  let!(:award_emoji4) { award_emoji.create!( name: 'thumbsup', awardable_type: 'Issue', awardable_id: issue4.id) }
+
+  it 'correctly schedules background migrations', :aggregate_failures do
+    stub_const("#{described_class.name}::BATCH_SIZE", 2)
+
+    Sidekiq::Testing.fake! do
+      freeze_time do
+        migrate!
+
+        expect(described_class::MIGRATION).to be_scheduled_migration(issue1.id, issue2.id)
+        expect(described_class::MIGRATION).to be_scheduled_migration(issue3.id, issue4.id)
+        expect(BackgroundMigrationWorker.jobs.size).to eq(2)
+      end
+    end
+  end
+end
+```
+
 ## Testing a non-`ActiveRecord::Migration` class
 
 To test a non-`ActiveRecord::Migration` test (a background migration),
diff --git a/doc/topics/autodevops/customize.md b/doc/topics/autodevops/customize.md
index 1e81fbf7756..72f688a0ed5 100644
--- a/doc/topics/autodevops/customize.md
+++ b/doc/topics/autodevops/customize.md
@@ -383,6 +383,7 @@ applications.
 | `AUTO_DEVOPS_CHART_REPOSITORY_NAME`     | From GitLab 11.11, used to set the name of the Helm repository. Defaults to `gitlab`. |
 | `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME` | From GitLab 11.11, used to set a username to connect to the Helm repository. Defaults to no credentials. Also set `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD`. |
 | `AUTO_DEVOPS_CHART_REPOSITORY_PASSWORD` | From GitLab 11.11, used to set a password to connect to the Helm repository. Defaults to no credentials. Also set `AUTO_DEVOPS_CHART_REPOSITORY_USERNAME`. |
+| `AUTO_DEVOPS_CHART_REPOSITORY_PASS_CREDENTIALS` | From GitLab 14.2, set to a non-empty value to enable forwarding of the Helm repository credentials to the chart server when the chart artifacts are on a different host than repository. |
 | `AUTO_DEVOPS_DEPLOY_DEBUG`              | From GitLab 13.1, if this variable is present, Helm outputs debug logs. |
 | `AUTO_DEVOPS_ALLOW_TO_FORCE_DEPLOY_V<N>` | From [auto-deploy-image](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image) v1.0.0, if this variable is present, a new major version of chart is forcibly deployed. For more information, see [Ignore warnings and continue deploying](upgrading_auto_deploy_dependencies.md#ignore-warnings-and-continue-deploying). |
 | `BUILDPACK_URL`                         | Buildpack's full URL. [Must point to a URL supported by Pack or Herokuish](#custom-buildpacks). |
diff --git a/doc/user/admin_area/license.md b/doc/user/admin_area/license.md
index 15af1a09a62..49ffc82982a 100644
--- a/doc/user/admin_area/license.md
+++ b/doc/user/admin_area/license.md
@@ -17,7 +17,7 @@ is locked.
 
 ## Activate GitLab EE with an Activation Code **(PREMIUM SELF)**
 
-As of GitLab Enterprise Edition 14.0, you need an activation code to activate your instance. You can obtain an activation code by [purchasing a license](https://about.gitlab.com/pricing/) or by signing up for a [free trial](https://about.gitlab.com/free-trial/). This activation code is a 24-character alphanumeric string you receive in a confirmation email. You can also sign in to the [Customers Portal](https://customers.gitlab.com/customers/sign_in) to copy the activation code to your clipboard.
+As of GitLab Enterprise Edition 14.1, you need an activation code to activate your instance. You can obtain an activation code by [purchasing a license](https://about.gitlab.com/pricing/) or by signing up for a [free trial](https://about.gitlab.com/free-trial/). This activation code is a 24-character alphanumeric string you receive in a confirmation email. You can also sign in to the [Customers Portal](https://customers.gitlab.com/customers/sign_in) to copy the activation code to your clipboard.
 
 To begin the activation process with your activation code:
 
@@ -155,4 +155,8 @@ and how to add additional seats can be found in the
 
 ### There is a connectivity issue
 
-In GitLab 14.0 and later, to activate your subscription, your GitLab instance must be connected to the internet. If you have questions or need assistance activating your instance please [contact GitLab Support](https://about.gitlab.com/support/#contact-support).
+In GitLab 14.1 and later, to activate your subscription, your GitLab instance must be connected to the internet. 
+
+If you have an offline or airgapped environment, you can [upload a license file](license.md#activate-gitlab-ee-with-a-license-file) instead.
+
+If you have questions or need assistance activating your instance, please [contact GitLab Support](https://about.gitlab.com/support/#contact-support).
diff --git a/doc/user/packages/dependency_proxy/index.md b/doc/user/packages/dependency_proxy/index.md
index cd504851b1f..b1064ac9844 100644
--- a/doc/user/packages/dependency_proxy/index.md
+++ b/doc/user/packages/dependency_proxy/index.md
@@ -20,7 +20,7 @@ upstream image from a registry, acting as a pull-through cache.
 
 ## Prerequisites
 
-The Dependency Proxy must be [enabled by an administrator](../../../administration/packages/dependency_proxy.md).
+- The Dependency Proxy is enabled by default but can be [turned off by an administrator](../../../administration/packages/dependency_proxy.md).
 
 ### Supported images and packages
 
@@ -33,11 +33,6 @@ The following images and packages are supported.
 For a list of planned additions, view the
 [direction page](https://about.gitlab.com/direction/package/#dependency-proxy).
 
-## Enable the Dependency Proxy
-
-The Dependency Proxy is disabled by default.
-[Learn how an administrator can enable it](../../../administration/packages/dependency_proxy.md).
-
 ## View the Dependency Proxy
 
 To view the Dependency Proxy: