Merge branch 'remove-product-prefixes-from-codebase' into 'master'

Remove product suffixes from codebase

See merge request gitlab-org/gitlab!39715

app/assets/javascripts/commit/pipelines/pipelines_table.vue

@@ -247,7 +247,7 @@ export default {
             }}
           </p>
           <gl-link
-            href="/help/ci/merge_request_pipelines/index.html#run-pipelines-in-the-parent-project-for-merge-requests-from-a-forked-project-starter"
+            href="/help/ci/merge_request_pipelines/index.html#run-pipelines-in-the-parent-project-for-merge-requests-from-a-forked-project"
             target="_blank"
           >
             {{ s__('Pipelines|More Information') }}

app/helpers/projects_helper.rb

@@ -640,7 +640,7 @@ module ProjectsHelper
       pagesAvailable: Gitlab.config.pages.enabled,
       pagesAccessControlEnabled: Gitlab.config.pages.access_control,
       pagesAccessControlForced: ::Gitlab::Pages.access_control_is_forced?,
-      pagesHelpPath: help_page_path('user/project/pages/introduction', anchor: 'gitlab-pages-access-control-core')
+      pagesHelpPath: help_page_path('user/project/pages/introduction', anchor: 'gitlab-pages-access-control')
     }
   end
 

app/presenters/clusters/cluster_presenter.rb

@@ -79,7 +79,7 @@ module Clusters
       {
         'clusters-path': clusterable.index_path,
         'dashboard-endpoint': clusterable.metrics_dashboard_path(cluster),
-        'documentation-path': help_page_path('user/project/clusters/index', anchor: 'monitoring-your-kubernetes-cluster-ultimate'),
+        'documentation-path': help_page_path('user/project/clusters/index', anchor: 'monitoring-your-kubernetes-cluster'),
         'add-dashboard-documentation-path': help_page_path('operations/metrics/dashboards/index.md', anchor: 'add-a-new-dashboard-to-your-project'),
         'empty-getting-started-svg-path': image_path('illustrations/monitoring/getting_started.svg'),
         'empty-loading-svg-path': image_path('illustrations/monitoring/loading.svg'),

app/views/admin/application_settings/_ci_cd.html.haml

@@ -34,13 +34,13 @@
       = f.number_field :max_artifacts_size, class: 'form-control'
       .form-text.text-muted
         = _("Set the maximum file size for each job's artifacts")
-        = link_to icon('question-circle'), help_page_path('user/admin_area/settings/continuous_integration', anchor: 'maximum-artifacts-size-core-only')
+        = link_to icon('question-circle'), help_page_path('user/admin_area/settings/continuous_integration', anchor: 'maximum-artifacts-size')
     .form-group
       = f.label :default_artifacts_expire_in, _('Default artifacts expiration'), class: 'label-bold'
       = f.text_field :default_artifacts_expire_in, class: 'form-control'
       .form-text.text-muted
         = html_escape(_("Set the default expiration time for each job's artifacts. 0 for unlimited. The default unit is in seconds, but you can define an alternative. For example: %{code_open}4 mins 2 sec%{code_close}, %{code_open}2h42min%{code_close}.")) % { code_open: '<code>'.html_safe, code_close: '</code>'.html_safe }
-        = link_to icon('question-circle'), help_page_path('user/admin_area/settings/continuous_integration', anchor: 'default-artifacts-expiration-core-only')
+        = link_to icon('question-circle'), help_page_path('user/admin_area/settings/continuous_integration', anchor: 'default-artifacts-expiration')
     .form-group
       = f.label :archive_builds_in_human_readable, _('Archive jobs'), class: 'label-bold'
       = f.text_field :archive_builds_in_human_readable, class: 'form-control', placeholder: 'never'

app/views/admin/application_settings/_usage.html.haml

@@ -11,7 +11,7 @@
           Enable version check
         .form-text.text-muted
           GitLab will inform you if a new version is available.
-          = link_to 'Learn more', help_page_path('user/admin_area/settings/usage_statistics', anchor: 'version-check-core-only')
+          = link_to 'Learn more', help_page_path('user/admin_area/settings/usage_statistics', anchor: 'version-check')
           about what information is shared with GitLab Inc.
     .form-group
       - can_be_configured = @application_setting.usage_ping_can_be_configured?
@@ -23,7 +23,7 @@
           - if can_be_configured
             %p.mb-2= _('To help improve GitLab and its user experience, GitLab will periodically collect usage information.')
 
-            - usage_ping_path = help_page_path('user/admin_area/settings/usage_statistics', anchor: 'usage-ping-core-only')
+            - usage_ping_path = help_page_path('user/admin_area/settings/usage_statistics', anchor: 'usage-ping')
             - usage_ping_link_start = '<a href="%{url}" target="_blank" rel="noopener noreferrer">'.html_safe % { url: usage_ping_path }
             %p.mb-2= s_('%{usage_ping_link_start}Learn more%{usage_ping_link_end} about what information is shared with GitLab Inc.').html_safe % { usage_ping_link_start: usage_ping_link_start, usage_ping_link_end: '</a>'.html_safe }
 

app/views/clusters/clusters/aws/_new.html.haml

 - if !Gitlab::CurrentSettings.eks_integration_enabled?
   - documentation_link_start = '<a href="%{url}" target="_blank" rel="noopener noreferrer">'.html_safe % { url: help_page_path('user/project/clusters/add_eks_clusters.md',
-      anchor: 'additional-requirements-for-self-managed-instances-core-only') }
+      anchor: 'additional-requirements-for-self-managed-instances') }
   = s_('Amazon authentication is not %{link_start}correctly configured%{link_end}. Ask your GitLab administrator if you want to use this service.').html_safe % { link_start: documentation_link_start, link_end: '<a/>'.html_safe }
 - else
   .js-create-eks-cluster-form-container{ data: { 'gitlab-managed-cluster-help-path' => help_page_path('user/project/clusters/index.md', anchor: 'gitlab-managed-clusters'),

app/views/groups/settings/ci_cd/_form.html.haml

@@ -8,6 +8,6 @@
           = f.number_field :max_artifacts_size, class: 'form-control'
           %p.form-text.text-muted
             = _("Set the maximum file size for each job's artifacts")
-            = link_to icon('question-circle'), help_page_path('user/admin_area/settings/continuous_integration', anchor: 'maximum-artifacts-size-core-only'), target: '_blank'
+            = link_to icon('question-circle'), help_page_path('user/admin_area/settings/continuous_integration', anchor: 'maximum-artifacts-size'), target: '_blank'
 
         = f.submit _('Save changes'), class: "btn btn-success"

app/views/projects/merge_requests/_widget.html.haml

@@ -7,7 +7,7 @@
     window.gl.mrWidgetData.ci_troubleshooting_docs_path = '#{help_page_path('ci/troubleshooting.md')}';
     window.gl.mrWidgetData.mr_troubleshooting_docs_path = '#{help_page_path('user/project/merge_requests/reviewing_and_managing_merge_requests.md', anchor: 'troubleshooting')}';
     window.gl.mrWidgetData.pipeline_must_succeed_docs_path = '#{help_page_path('user/project/merge_requests/merge_when_pipeline_succeeds.md', anchor: 'only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds')}';
-    window.gl.mrWidgetData.security_approvals_help_page_path = '#{help_page_path('user/application_security/index.md', anchor: 'security-approvals-in-merge-requests-ultimate')}';
+    window.gl.mrWidgetData.security_approvals_help_page_path = '#{help_page_path('user/application_security/index.md', anchor: 'security-approvals-in-merge-requests')}';
     window.gl.mrWidgetData.eligible_approvers_docs_path = '#{help_page_path('user/project/merge_requests/merge_request_approvals', anchor: 'eligible-approvers')}';
     window.gl.mrWidgetData.approvals_help_path = '#{help_page_path("user/project/merge_requests/merge_request_approvals")}';
     window.gl.mrWidgetData.pipelines_empty_svg_path = '#{image_path('illustrations/pipelines_empty.svg')}';

app/views/projects/mirrors/_mirror_repos_push.html.haml

@@ -10,4 +10,4 @@
   .form-check.gl-mb-3
     = check_box_tag :keep_divergent_refs, '1', false, class: 'js-mirror-keep-divergent-refs form-check-input'
     = label_tag :keep_divergent_refs, _('Keep divergent refs'), class: 'form-check-label'
-    = link_to icon('question-circle'), help_page_path('user/project/repository/repository_mirroring', anchor: 'keep-divergent-refs-core'), target: '_blank'
+    = link_to icon('question-circle'), help_page_path('user/project/repository/repository_mirroring', anchor: 'keep-divergent-refs'), target: '_blank'

app/views/projects/settings/ci_cd/_autodevops_form.html.haml

@@ -46,12 +46,12 @@
                   = form.radio_button :deploy_strategy, 'timed_incremental', class: 'form-check-input'
                   = form.label :deploy_strategy_timed_incremental, class: 'form-check-label' do
                     = s_('CICD|Continuous deployment to production using timed incremental rollout')
-                    = link_to icon('question-circle'), help_page_path('topics/autodevops/customize.md', anchor: 'timed-incremental-rollout-to-production-premium'), target: '_blank'
+                    = link_to icon('question-circle'), help_page_path('topics/autodevops/customize.md', anchor: 'timed-incremental-rollout-to-production'), target: '_blank'
 
                 .form-check
                   = form.radio_button :deploy_strategy, 'manual', class: 'form-check-input'
                   = form.label :deploy_strategy_manual, class: 'form-check-label' do
                     = s_('CICD|Automatic deployment to staging, manual deployment to production')
-                    = link_to icon('question-circle'), help_page_path('topics/autodevops/customize.md', anchor: 'incremental-rollout-to-production-premium'), target: '_blank'
+                    = link_to icon('question-circle'), help_page_path('topics/autodevops/customize.md', anchor: 'incremental-rollout-to-production'), target: '_blank'
 
           = f.submit _('Save changes'), class: "btn btn-success gl-mt-5", data: { qa_selector: 'save_changes_button' }

app/views/projects/settings/ci_cd/_form.html.haml

@@ -47,7 +47,7 @@
             = f.number_field :max_artifacts_size, class: 'form-control'
             %p.form-text.text-muted
               = _("Set the maximum file size for each job's artifacts")
-              = link_to icon('question-circle'), help_page_path('user/admin_area/settings/continuous_integration', anchor: 'maximum-artifacts-size-core-only'), target: '_blank'
+              = link_to icon('question-circle'), help_page_path('user/admin_area/settings/continuous_integration', anchor: 'maximum-artifacts-size'), target: '_blank'
 
         %hr
         .form-group

app/views/shared/empty_states/_issues.html.haml

@@ -51,7 +51,7 @@
           %strong
             = s_('JiraService|Using Jira for issue tracking?')
         %p.gl-text-center.gl-mb-0
-          - jira_docs_link_url = help_page_url('user/project/integrations/jira', anchor: 'view-jira-issues-premium')
+          - jira_docs_link_url = help_page_url('user/project/integrations/jira', anchor: 'view-jira-issues')
           - jira_docs_link_start = '<a href="%{url}" target="_blank" rel="noopener noreferrer">'.html_safe % { url: jira_docs_link_url }
           = html_escape(s_('JiraService|%{jira_docs_link_start}Enable the Jira integration%{jira_docs_link_end} to view your Jira issues in GitLab.')) % { jira_docs_link_start: jira_docs_link_start.html_safe, jira_docs_link_end: '</a>'.html_safe }
         %p.gl-text-center.gl-mb-0.gl-text-gray-500

data/whats_new/202008180001_12_10.yml

@@ -25,7 +25,7 @@
   self-managed: true
   gitlab-com: true
   packages: [Ultimate, Gold]
-  url: https://docs.gitlab.com/ee/user/project/issues/index.html#health-status-ultimate
+  url: https://docs.gitlab.com/ee/user/project/issues/index.html#health-status
   image_url: https://about.gitlab.com/images/12_10/epic-health-status.png
   published_at: 2020-04-22
   release: 12.10

doc/administration/audit_events.md

@@ -68,7 +68,7 @@ From there, you can see the following actions:
 - Roles allowed to create project changed.
 - Group CI/CD variable added, removed, or protected status changed. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30857) in GitLab 13.3.
 
-Group events can also be accessed via the [Group Audit Events API](../api/audit_events.md#group-audit-events-starter)
+Group events can also be accessed via the [Group Audit Events API](../api/audit_events.md#group-audit-events)
 
 ### Project events **(STARTER)**
 
@@ -98,7 +98,7 @@ From there, you can see the following actions:
 - Added or removed users and groups from project approval groups ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/213603) in GitLab 13.2)
 - Project CI/CD variable added, removed, or protected status changed. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30857) in GitLab 13.4.
 
-Project events can also be accessed via the [Project Audit Events API](../api/audit_events.md#project-audit-events-starter)
+Project events can also be accessed via the [Project Audit Events API](../api/audit_events.md#project-audit-events)
 
 ### Instance events **(PREMIUM ONLY)**
 
@@ -133,7 +133,7 @@ the filter dropdown box. You can further filter by specific group, project, or u
 
 ![audit log](img/audit_log.png)
 
-Instance events can also be accessed via the [Instance Audit Events API](../api/audit_events.md#instance-audit-events-premium-only)
+Instance events can also be accessed via the [Instance Audit Events API](../api/audit_events.md#instance-audit-events)
 
 ### Missing events
 

doc/administration/auth/ldap/google_secure_ldap.md

@@ -35,7 +35,7 @@ The steps below cover:
    credentials' and 'Read user information'. Select 'Add LDAP Client'
 
    TIP: **Tip:**
-   If you plan to use GitLab [LDAP Group Sync](index.md#group-sync-starter-only)
+   If you plan to use GitLab [LDAP Group Sync](index.md#group-sync)
    , turn on 'Read group information'.
 
    ![Add LDAP Client Step 2](img/google_secure_ldap_add_step_2.png)

doc/administration/auth/ldap/index.md

@@ -37,7 +37,7 @@ GitLab assumes that LDAP users:
 
 - Are not able to change their LDAP `mail`, `email`, or `userPrincipalName` attributes.
   An LDAP user who is allowed to change their email on the LDAP server can potentially
-  [take over any account](#enabling-ldap-sign-in-for-existing-gitlab-users-core-only)
+  [take over any account](#enabling-ldap-sign-in-for-existing-gitlab-users)
   on your GitLab server.
 - Have unique email addresses, otherwise it is possible for LDAP users with the same
   email address to share the same GitLab account.
@@ -57,7 +57,7 @@ immediately block all access.
 
 NOTE: **Note:**
 GitLab Enterprise Edition Starter supports a
-[configurable sync time](#adjusting-ldap-user-sync-schedule-starter-only).
+[configurable sync time](#adjusting-ldap-user-sync-schedule).
 
 ## Git password authentication **(CORE ONLY)**
 
@@ -340,7 +340,7 @@ sync, while also allowing your SAML identity provider to handle additional
 checks like custom 2FA.
 
 When LDAP web sign in is disabled, users will not see a **LDAP** tab on the sign in page.
-This does not disable [using LDAP credentials for Git access](#git-password-authentication-core-only).
+This does not disable [using LDAP credentials for Git access](#git-password-authentication).
 
 **Omnibus configuration**
 
@@ -391,7 +391,7 @@ that your GitLab instance will connect to.
 
 To add another LDAP server:
 
-1. Duplicate the settings under [the main configuration](#configuration-core-only).
+1. Duplicate the settings under [the main configuration](#configuration).
 1. Edit them to match the additional LDAP server.
 
 Be sure to choose a different provider ID made of letters a-z and numbers 0-9.
@@ -546,11 +546,11 @@ following.
 1. [Restart GitLab](../../restart_gitlab.md#installations-from-source) for the changes to take effect.
 
 To take advantage of group sync, group owners or maintainers will need to [create one
-or more LDAP group links](#adding-group-links-starter-only).
+or more LDAP group links](#adding-group-links).
 
 ### Adding group links **(STARTER ONLY)**
 
-For information on adding group links via CNs and filters, refer to [the GitLab groups documentation](../../../user/group/index.md#manage-group-memberships-via-ldap-starter-only).
+For information on adding group links via CNs and filters, refer to [the GitLab groups documentation](../../../user/group/index.md#manage-group-memberships-via-ldap).
 
 ### Administrator sync **(STARTER ONLY)**
 
@@ -611,7 +611,7 @@ When enabled, the following applies:
 
 To enable it you need to:
 
-1. [Enable LDAP](#configuration-core-only)
+1. [Enable LDAP](#configuration)
 1. Navigate to **(admin)** **Admin Area > Settings -> Visibility and access controls**.
 1. Make sure the "Lock memberships to LDAP synchronization" checkbox is enabled.
 
@@ -659,7 +659,7 @@ sync to run once every 2 hours at the top of the hour.
 ### External groups **(STARTER ONLY)**
 
 Using the `external_groups` setting will allow you to mark all users belonging
-to these groups as [external users](../../../user/permissions.md#external-users-core-only).
+to these groups as [external users](../../../user/permissions.md#external-users).
 Group membership is checked periodically through the `LdapGroupSync` background
 task.
 

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

@@ -56,7 +56,7 @@ main: # 'main' is the GitLab 'provider ID' of this LDAP server
 
 The following allows you to perform a search in LDAP using the rails console.
 Depending on what you're trying to do, it may make more sense to query [a
-user](#query-a-user-in-ldap) or [a group](#query-a-group-in-ldap-starter-only) directly, or
+user](#query-a-user-in-ldap) or [a group](#query-a-group-in-ldap) directly, or
 even [use `ldapsearch`](#ldapsearch) instead.
 
 ```ruby
@@ -90,8 +90,8 @@ established but GitLab doesn't show you LDAP users in the output, one of the
 following is most likely true:
 
 - The `bind_dn` user doesn't have enough permissions to traverse the user tree.
-- The user(s) don't fall under the [configured `base`](index.md#configuration-core-only).
-- The [configured `user_filter`](index.md#set-up-ldap-user-filter-core-only) blocks access to the user(s).
+- The user(s) don't fall under the [configured `base`](index.md#configuration).
+- The [configured `user_filter`](index.md#set-up-ldap-user-filter) blocks access to the user(s).
 
 In this case, you con confirm which of the above is true using
 [ldapsearch](#ldapsearch) with the existing LDAP configuration in your
@@ -102,9 +102,9 @@ In this case, you con confirm which of the above is true using
 A user can have trouble signing in for any number of reasons. To get started,
 here are some questions to ask yourself:
 
-- Does the user fall under the [configured `base`](index.md#configuration-core-only) in
+- Does the user fall under the [configured `base`](index.md#configuration) in
   LDAP? The user must fall under this `base` to sign-in.
-- Does the user pass through the [configured `user_filter`](index.md#set-up-ldap-user-filter-core-only)?
+- Does the user pass through the [configured `user_filter`](index.md#set-up-ldap-user-filter)?
   If one is not configured, this question can be ignored. If it is, then the
   user must also pass through this filter to be allowed to sign-in.
   - Refer to our docs on [debugging the `user_filter`](#debug-ldap-user-filter).
@@ -122,7 +122,7 @@ If the logs don't lead to the root of the problem, use the
 to see if GitLab can read this user on the LDAP server.
 
 It can also be helpful to
-[debug a user sync](#sync-all-users-starter-only) to
+[debug a user sync](#sync-all-users) to
 investigate further.
 
 #### Invalid credentials on sign-in
@@ -196,7 +196,7 @@ profile](../../../user/profile/index.md#user-profile) or an admin can do it.
 #### Debug LDAP user filter
 
 [`ldapsearch`](#ldapsearch) allows you to test your configured
-[user filter](index.md#set-up-ldap-user-filter-core-only)
+[user filter](index.md#set-up-ldap-user-filter)
 to confirm that it returns the users you expect it to return.
 
 ```shell
@@ -212,7 +212,7 @@ ldapsearch -H ldaps://$host:$port -D "$bind_dn" -y bind_dn_password.txt  -b "$ba
 
 #### Sync all users **(STARTER ONLY)**
 
-The output from a manual [user sync](index.md#user-sync-starter-only) can show you what happens when
+The output from a manual [user sync](index.md#user-sync) can show you what happens when
 GitLab tries to sync its users against LDAP. Enter the [rails console](#rails-console)
 and then run:
 
@@ -223,11 +223,11 @@ LdapSyncWorker.new.perform
 ```
 
 Next, [learn how to read the
-output](#example-console-output-after-a-user-sync-starter-only).
+output](#example-console-output-after-a-user-sync).
 
 ##### Example console output after a user sync **(STARTER ONLY)**
 
-The output from a [manual user sync](#sync-all-users-starter-only) will be very verbose, and a
+The output from a [manual user sync](#sync-all-users) will be very verbose, and a
 single user's successful sync can look like this:
 
 ```shell
@@ -325,9 +325,9 @@ LDAP group sync, but for some reason it's not happening. There are several
 things to check to debug the situation.
 
 - Ensure LDAP configuration has a `group_base` specified.
-  [This configuration](index.md#group-sync-starter-only) is required for group sync to work properly.
+  [This configuration](index.md#group-sync) is required for group sync to work properly.
 - Ensure the correct [LDAP group link is added to the GitLab
-  group](index.md#adding-group-links-starter-only).
+  group](index.md#adding-group-links).
 - Check that the user has an LDAP identity:
   1. Sign in to GitLab as an administrator user.
   1. Navigate to **Admin area -> Users**.
@@ -337,10 +337,10 @@ things to check to debug the situation.
      an LDAP DN as the 'Identifier'. If not, this user hasn't signed in with
      LDAP yet and must do so first.
 - You've waited an hour or [the configured
-  interval](index.md#adjusting-ldap-group-sync-schedule-starter-only) for the group to
+  interval](index.md#adjusting-ldap-group-sync-schedule) for the group to
   sync. To speed up the process, either go to the GitLab group **Settings ->
   Members** and press **Sync now** (sync one group) or [run the group sync Rake
-  task](../../raketasks/ldap.md#run-a-group-sync-starter-only) (sync all groups).
+  task](../../raketasks/ldap.md#run-a-group-sync) (sync all groups).
 
 If all of the above looks good, jump in to a little more advanced debugging in
 the rails console.
@@ -348,23 +348,23 @@ the rails console.
 1. Enter the [rails console](#rails-console).
 1. Choose a GitLab group to test with. This group should have an LDAP group link
    already configured.
-1. [Enable debug logging, find the above GitLab group, and sync it with LDAP](#sync-one-group-starter-only).
+1. [Enable debug logging, find the above GitLab group, and sync it with LDAP](#sync-one-group).
 1. Look through the output of the sync. See [example log
-   output](#example-console-output-after-a-group-sync-starter-only)
+   output](#example-console-output-after-a-group-sync)
    for how to read the output.
 1. If you still aren't able to see why the user isn't being added, [query the
-   LDAP group directly](#query-a-group-in-ldap-starter-only) to see what members are listed.
+   LDAP group directly](#query-a-group-in-ldap) to see what members are listed.
 1. Is the user's DN or UID in one of the lists from the above output? One of the DNs or
    UIDs here should match the 'Identifier' from the LDAP identity checked earlier. If it doesn't,
    the user does not appear to be in the LDAP group.
 
 #### Admin privileges not granted
 
-When [Administrator sync](index.md#administrator-sync-starter-only) has been configured
+When [Administrator sync](index.md#administrator-sync) has been configured
 but the configured users aren't granted the correct admin privileges, confirm
 the following are true:
 
-- A [`group_base` is also configured](index.md#group-sync-starter-only).
+- A [`group_base` is also configured](index.md#group-sync).
 - The configured `admin_group` in the `gitlab.rb` is a CN, rather than a DN or an array.
 - This CN falls under the scope of the configured `group_base`.
 - The members of the `admin_group` have already signed into GitLab with their LDAP
@@ -372,17 +372,17 @@ the following are true:
   accounts are already connected to LDAP.
 
 If all the above are true and the users are still not getting access, [run a manual
-group sync](#sync-all-groups-starter-only) in the rails console and [look through the
-output](#example-console-output-after-a-group-sync-starter-only) to see what happens when
+group sync](#sync-all-groups) in the rails console and [look through the
+output](#example-console-output-after-a-group-sync) to see what happens when
 GitLab syncs the `admin_group`.
 
 #### Sync all groups **(STARTER ONLY)**
 
 NOTE: **Note:**
 To sync all groups manually when debugging is unnecessary, [use the Rake
-task](../../raketasks/ldap.md#run-a-group-sync-starter-only) instead.
+task](../../raketasks/ldap.md#run-a-group-sync) instead.
 
-The output from a manual [group sync](index.md#group-sync-starter-only) can show you what happens
+The output from a manual [group sync](index.md#group-sync) can show you what happens
 when GitLab syncs its LDAP group memberships against LDAP.
 
 ```ruby
@@ -392,12 +392,12 @@ LdapAllGroupsSyncWorker.new.perform
 ```
 
 Next, [learn how to read the
-output](#example-console-output-after-a-group-sync-starter-only).
+output](#example-console-output-after-a-group-sync).
 
 ##### Example console output after a group sync **(STARTER ONLY)**
 
 Like the output from the user sync, the output from the [manual group
-sync](#sync-all-groups-starter-only) will also be very verbose. However, it contains lots
+sync](#sync-all-groups) will also be very verbose. However, it contains lots
 of helpful information.
 
 Indicates the point where syncing actually begins:
@@ -477,7 +477,7 @@ this line will indicate the sync is finished:
 Finished syncing admin users for 'ldapmain' provider
 ```
 
-If [admin sync](index.md#administrator-sync-starter-only) is not configured, you'll see a message
+If [admin sync](index.md#administrator-sync) is not configured, you'll see a message
 stating as such:
 
 ```shell
@@ -486,7 +486,7 @@ No `admin_group` configured for 'ldapmain' provider. Skipping
 
 #### Sync one group **(STARTER ONLY)**
 
-[Syncing all groups](#sync-all-groups-starter-only) can produce a lot of noise in the output, which can be
+[Syncing all groups](#sync-all-groups) can produce a lot of noise in the output, which can be
 distracting when you're only interested in troubleshooting the memberships of
 a single GitLab group. In that case, here's how you can just sync this group
 and see its debug output:
@@ -504,7 +504,7 @@ EE::Gitlab::Auth::Ldap::Sync::Group.execute_all_providers(group)
 ```
 
 The output will be similar to
-[that you'd get from syncing all groups](#example-console-output-after-a-group-sync-starter-only).
+[that you'd get from syncing all groups](#example-console-output-after-a-group-sync).
 
 #### Query a group in LDAP **(STARTER ONLY)**
 
@@ -562,7 +562,7 @@ emails.each do |username, email|
 end
 ```
 
-You can then [run a UserSync](#sync-all-users-starter-only) **(STARTER ONLY)** to sync the latest DN
+You can then [run a UserSync](#sync-all-users) **(STARTER ONLY)** to sync the latest DN
 for each of these users.
 
 ## Debugging Tools

doc/administration/compliance.md

@@ -11,10 +11,10 @@ GitLab’s [security features](../security/README.md) may also help you meet rel
 |**[Enforce TOS acceptance](../user/admin_area/settings/terms.md)**<br>Enforce your users accepting new terms of service by blocking GitLab traffic.|Core+||
 |**[Email all users of a project, group, or entire server](../user/admin_area/settings/terms.md)**<br>An admin can email groups of users based on project or group membership, or email everyone using the GitLab instance. This is great for scheduled maintenance or upgrades.|Starter+||
 |**[Omnibus package supports log forwarding](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-forwarding)**<br>Forward your logs to a central system.|Starter+||
-|**[Lock project membership to group](../user/group/index.md#member-lock-starter)**<br>Group owners can prevent new members from being added to projects within a group.|Starter+|✓|
-|**[LDAP group sync](auth/ldap/index.md#group-sync-starter-only)**<br>GitLab Enterprise Edition gives admins the ability to automatically sync groups and manage SSH keys, permissions, and authentication, so you can focus on building your product, not configuring your tools.|Starter+||
-|**[LDAP group sync filters](auth/ldap/index.md#group-sync-starter-only)**<br>GitLab Enterprise Edition Premium gives more flexibility to synchronize with LDAP based on filters, meaning you can leverage LDAP attributes to map GitLab permissions.|Premium+||
+|**[Lock project membership to group](../user/group/index.md#member-lock)**<br>Group owners can prevent new members from being added to projects within a group.|Starter+|✓|
+|**[LDAP group sync](auth/ldap/index.md#group-sync)**<br>GitLab Enterprise Edition gives admins the ability to automatically sync groups and manage SSH keys, permissions, and authentication, so you can focus on building your product, not configuring your tools.|Starter+||
+|**[LDAP group sync filters](auth/ldap/index.md#group-sync)**<br>GitLab Enterprise Edition Premium gives more flexibility to synchronize with LDAP based on filters, meaning you can leverage LDAP attributes to map GitLab permissions.|Premium+||
 |**[Audit logs](audit_events.md)**<br>To maintain the integrity of your code, GitLab Enterprise Edition Premium gives admins the ability to view any modifications made within the GitLab server in an advanced audit log system, so you can control, analyze, and track every change.|Premium+||
 |**[Auditor users](auditor_users.md)**<br>Auditor users are users who are given read-only access to all projects, groups, and other resources on the GitLab instance.|Premium+||
 |**[Credentials inventory](../user/admin_area/credentials_inventory.md)**<br>With a credentials inventory, GitLab administrators can keep track of the credentials used by all of the users in their GitLab instance. |Ultimate||
-|**Separation of Duties using [Protected branches](../user/project/protected_branches.md#protected-branches-approval-by-code-owners-premium) and [custom CI Configuration Paths](../ci/pipelines/settings.md#custom-ci-configuration-path)**<br> GitLab Silver and Premium users can leverage GitLab's cross-project YAML configuration's to define deployers of code and developers of code. View the [Separation of Duties Deploy Project](https://gitlab.com/guided-explorations/separation-of-duties-deploy/blob/master/README.md) and [Separation of Duties Project](https://gitlab.com/guided-explorations/separation-of-duties/blob/master/README.md) to see how to use this set up to define these roles.|Premium+||
+|**Separation of Duties using [Protected branches](../user/project/protected_branches.md#protected-branches-approval-by-code-owners) and [custom CI Configuration Paths](../ci/pipelines/settings.md#custom-ci-configuration-path)**<br> GitLab Silver and Premium users can leverage GitLab's cross-project YAML configuration's to define deployers of code and developers of code. View the [Separation of Duties Deploy Project](https://gitlab.com/guided-explorations/separation-of-duties-deploy/blob/master/README.md) and [Separation of Duties Project](https://gitlab.com/guided-explorations/separation-of-duties/blob/master/README.md) to see how to use this set up to define these roles.|Premium+||

doc/administration/database_load_balancing.md

@@ -221,7 +221,7 @@ without it immediately leading to errors being presented to the users.
 ## Logging
 
 The load balancer logs various events in
-[`database_load_balancing.log`](logs.md#database_load_balancinglog-premium-only), such as
+[`database_load_balancing.log`](logs.md#database_load_balancinglog), such as
 
 - When a host is marked as offline
 - When a host comes back online

doc/administration/geo/replication/datatypes.md

@@ -134,7 +134,7 @@ The replication for some data types is behind a corresponding feature flag:
 > - They're enabled on GitLab.com.
 > - They can't be enabled or disabled per-project.
 > - They are recommended for production use.
-> - For GitLab self-managed instances, GitLab administrators can opt to [disable them](#enable-or-disable-replication-for-some-data-types-core-only). **(CORE ONLY)**
+> - For GitLab self-managed instances, GitLab administrators can opt to [disable them](#enable-or-disable-replication-for-some-data-types). **(CORE ONLY)**
 
 #### Enable or disable replication (for some data types) **(CORE ONLY)**
 

doc/administration/geo/replication/object_storage.md

@@ -44,7 +44,7 @@ For LFS, follow the documentation to
 For CI job artifacts, there is similar documentation to configure
 [jobs artifact object storage](../../job_artifacts.md#using-object-storage)
 
-For user uploads, there is similar documentation to configure [upload object storage](../../uploads.md#using-object-storage-core-only)
+For user uploads, there is similar documentation to configure [upload object storage](../../uploads.md#using-object-storage)
 
 If you want to migrate the **primary** node's files to object storage, you can
 configure the **secondary** in a few ways:

doc/administration/incoming_email.md

@@ -13,7 +13,7 @@ GitLab has several features based on receiving incoming emails:
 - [New issue by email](../user/project/issues/managing_issues.md#new-issue-via-email):
   allow GitLab users to create a new issue by sending an email to a
   user-specific email address.
-- [New merge request by email](../user/project/merge_requests/creating_merge_requests.md#new-merge-request-by-email-core-only):
+- [New merge request by email](../user/project/merge_requests/creating_merge_requests.md#new-merge-request-by-email):
   allow GitLab users to create a new merge request by sending an email to a
   user-specific email address.
 - [Service Desk](../user/project/service_desk.md): provide e-mail support to
@@ -95,7 +95,7 @@ email address in order to sign up.
 If you also host a public-facing GitLab instance at `hooli.com` and set your
 incoming email domain to `hooli.com`, an attacker could abuse the "Create new
 issue by email" or
-"[Create new merge request by email](../user/project/merge_requests/creating_merge_requests.md#new-merge-request-by-email-core-only)"
+"[Create new merge request by email](../user/project/merge_requests/creating_merge_requests.md#new-merge-request-by-email)"
 features by using a project's unique address as the email when signing up for
 Slack. This would send a confirmation email, which would create a new issue or
 merge request on the project owned by the attacker, allowing them to click the

doc/administration/index.md

@@ -73,7 +73,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 - [Favicon](../user/admin_area/appearance.md#favicon): Change the default favicon to your own logo.
 - [Branded login page](../user/admin_area/appearance.md#sign-in--sign-up-pages): Customize the login page with your own logo, title, and description.
 - ["New Project" page](../user/admin_area/appearance.md#new-project-pages): Customize the text to be displayed on the page that opens whenever your users create a new project.
-- [Additional custom email text](../user/admin_area/settings/email.md#custom-additional-text-premium-only): Add additional custom text to emails sent from GitLab. **(PREMIUM ONLY)**
+- [Additional custom email text](../user/admin_area/settings/email.md#custom-additional-text): Add additional custom text to emails sent from GitLab. **(PREMIUM ONLY)**
 
 ### Maintaining GitLab
 
@@ -120,7 +120,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 - [Auditor users](auditor_users.md): Users with read-only access to all projects, groups, and other resources on the GitLab instance. **(PREMIUM ONLY)**
 - [Incoming email](incoming_email.md): Configure incoming emails to allow
   users to [reply by email](reply_by_email.md), create [issues by email](../user/project/issues/managing_issues.md#new-issue-via-email) and
-  [merge requests by email](../user/project/merge_requests/creating_merge_requests.md#new-merge-request-by-email-core-only), and to enable [Service Desk](../user/project/service_desk.md).
+  [merge requests by email](../user/project/merge_requests/creating_merge_requests.md#new-merge-request-by-email), and to enable [Service Desk](../user/project/service_desk.md).
   - [Postfix for incoming email](reply_by_email_postfix_setup.md): Set up a
   basic Postfix mail server with IMAP authentication on Ubuntu for incoming
   emails.
@@ -158,7 +158,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 - [Job artifacts](job_artifacts.md): Enable, disable, and configure job artifacts (a set of files and directories which are outputted by a job when it completes successfully).
 - [Job logs](job_logs.md): Information about the job logs.
 - [Register Runners](../ci/runners/README.md#types-of-runners): Learn how to register and configure Runners.
-- [Shared Runners pipelines quota](../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota-starter-only): Limit the usage of pipeline minutes for Shared Runners. **(STARTER ONLY)**
+- [Shared Runners pipelines quota](../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota): Limit the usage of pipeline minutes for Shared Runners. **(STARTER ONLY)**
 - [Enable/disable Auto DevOps](../topics/autodevops/index.md#enablingdisabling-auto-devops): Enable or disable Auto DevOps for your instance.
 
 ## Snippet settings

doc/administration/instance_limits.md

@@ -321,7 +321,7 @@ Plan.default.actual_limits.update!(ci_instance_level_variables: 30)
 Job artifacts defined with [`artifacts:reports`](../ci/pipelines/job_artifacts.md#artifactsreports)
 that are uploaded by the Runner are rejected if the file size exceeds the maximum
 file size limit. The limit is determined by comparing the project's
-[maximum artifact size setting](../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size-core-only)
+[maximum artifact size setting](../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size)
 with the instance limit for the given artifact type, and choosing the smaller value.
 
 Limits are set in megabytes, so the smallest possible value that can be defined is `1 MB`.
@@ -434,7 +434,7 @@ Kubernetes won't be shown.
 
 Reports that go over the 20 MB limit won't be loaded. Affected reports:
 
-- [Merge Request security reports](../user/project/merge_requests/testing_and_reports_in_merge_requests.md#security-reports-ultimate)
+- [Merge Request security reports](../user/project/merge_requests/testing_and_reports_in_merge_requests.md#security-reports)
 - [CI/CD parameter `artifacts:expose_as`](../ci/yaml/README.md#artifactsexpose_as)
 - [Unit test reports](../ci/unit_test_reports.md)
 

doc/administration/job_artifacts.md

@@ -404,7 +404,7 @@ you can enable the `ci_disable_validates_dependencies` feature flag from a Rails
 ## Set the maximum file size of the artifacts
 
 If artifacts are enabled, you can change the maximum file size of the
-artifacts through the [Admin Area settings](../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size-core-only).
+artifacts through the [Admin Area settings](../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size).
 
 ## Storage statistics
 

doc/administration/monitoring/gitlab_self_monitoring_project/index.md

@@ -77,7 +77,7 @@ You can [add a webhook](../../../operations/metrics/alerts.md#external-prometheu
 to the Prometheus configuration in order for GitLab to receive notifications of any alerts.
 
 Once the webhook is setup, you can
-[take action on incoming alerts](../../../operations/metrics/alerts.md#trigger-actions-from-alerts-ultimate).
+[take action on incoming alerts](../../../operations/metrics/alerts.md#trigger-actions-from-alerts).
 
 ## Adding custom metrics to the self monitoring project
 
@@ -93,7 +93,7 @@ You can add custom metrics in the self monitoring project by:
 There is [a bug](https://gitlab.com/gitlab-org/gitlab/-/issues/208676) which causes
 project creation to fail with the following error (which appears in the log file)
 when the first admin user is an
-[external user](../../../user/permissions.md#external-users-core-only):
+[external user](../../../user/permissions.md#external-users):
 
 ```plaintext
 Could not create instance administrators group. Errors: ["You don’t have permission to create groups."]
@@ -108,6 +108,6 @@ User.admins.active.first.external?
 If this returns true, the first admin user is an external user.
 
 If you face this issue, you can temporarily
-[make the admin user a non-external user](../../../user/permissions.md#external-users-core-only)
+[make the admin user a non-external user](../../../user/permissions.md#external-users)
 and then try to create the project.
 Once the project is created, the admin user can be changed back to an external user.

doc/administration/object_storage.md

@@ -505,7 +505,7 @@ supported by consolidated configuration form, refer to the following guides:
 | [Backups](../raketasks/backup_restore.md#uploading-backups-to-a-remote-cloud-storage)|No|
 | [Job artifacts](job_artifacts.md#using-object-storage) and [incremental logging](job_logs.md#new-incremental-logging-architecture) | Yes |
 | [LFS objects](lfs/index.md#storing-lfs-objects-in-remote-object-storage) | Yes |
-| [Uploads](uploads.md#using-object-storage-core-only) | Yes |
+| [Uploads](uploads.md#using-object-storage) | Yes |
 | [Container Registry](packages/container_registry.md#use-object-storage) (optional feature) | No |
 | [Merge request diffs](merge_request_diffs.md#using-object-storage) | Yes |
 | [Mattermost](https://docs.mattermost.com/administration/config-settings.html#file-storage)| No |
@@ -513,7 +513,7 @@ supported by consolidated configuration form, refer to the following guides:
 | [Dependency Proxy](packages/dependency_proxy.md#using-object-storage) (optional feature) **(PREMIUM ONLY)** | Yes |
 | [Pseudonymizer](pseudonymizer.md#configuration) (optional feature) **(ULTIMATE ONLY)** | No |
 | [Autoscale Runner caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) (optional for improved performance) | No |
-| [Terraform state files](terraform_state.md#using-object-storage-core-only) | Yes |
+| [Terraform state files](terraform_state.md#using-object-storage) | Yes |
 
 ### Other alternatives to filesystem storage
 

doc/administration/pages/source.md

@@ -421,7 +421,7 @@ Pages access control is disabled by default. To enable it:
      auth-server=<URL of the GitLab instance>
    ```
 
-1. Users can now configure it in their [projects' settings](../../user/project/pages/introduction.md#gitlab-pages-access-control-core).
+1. Users can now configure it in their [projects' settings](../../user/project/pages/introduction.md#gitlab-pages-access-control).
 
 ## Change storage path
 

doc/administration/raketasks/ldap.md

@@ -32,13 +32,13 @@ rake gitlab:ldap:check[50]
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/14735) in [GitLab Starter](https://about.gitlab.com/pricing/) 12.2.
 
-The following task will run a [group sync](../auth/ldap/index.md#group-sync-starter-only) immediately. This is valuable
+The following task will run a [group sync](../auth/ldap/index.md#group-sync) immediately. This is valuable
 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:**
 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-starter-only)
+[adjust the cron schedule](../auth/ldap/index.md#adjusting-ldap-group-sync-schedule)
 instead.
 
 **Omnibus Installation**

doc/administration/raketasks/uploads/migrate.md

@@ -7,7 +7,7 @@ There is a Rake task for migrating uploads between different storage types.
 
 ## Migrate to object storage
 
-After [configuring the object storage](../../uploads.md#using-object-storage-core-only) for GitLab's
+After [configuring the object storage](../../uploads.md#using-object-storage) for GitLab's
 uploads, use this task to migrate existing uploads from the local storage to the remote storage.
 
 Read more about using [object storage with GitLab](../../object_storage.md).
@@ -168,18 +168,4 @@ To migrate uploads from object storage to local storage:
    ```
 
 After running the Rake task, you can disable object storage by undoing the changes described
-in the instructions to [configure object storage](../../uploads.md#using-object-storage-core-only).
-
-## Troubleshooting
-
-### undefined method constantize
-
-You will see the following error if you run `gitlab:uploads:migrate` without parameters.
-
-```plaintext
-rake aborted!
-NoMethodError: undefined method `constantize' for nil:NilClass
-```
-
-- If you intend to migrate all uploads, use the all-in-one Rake task [`gitlab:uploads:migrate:all`](#all-in-one-rake-task).
-- To migrate specific uploads, use [`gitlab:uploads:migrate`](#individual-rake-tasks) and supply the necessary parameters.
+in the instructions to [configure object storage](../../uploads.md#using-object-storage).

doc/administration/reference_architectures/10k_users.md

@@ -1993,7 +1993,7 @@ based on what features you intend to use:
 1. Configure [object storage for job artifacts](../job_artifacts.md#using-object-storage)
    including [incremental logging](../job_logs.md#new-incremental-logging-architecture).
 1. Configure [object storage for LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage).
-1. Configure [object storage for uploads](../uploads.md#using-object-storage-core-only).
+1. Configure [object storage for uploads](../uploads.md#using-object-storage).
 1. Configure [object storage for merge request diffs](../merge_request_diffs.md#using-object-storage).
 1. Configure [object storage for Container Registry](../packages/container_registry.md#use-object-storage) (optional feature).
 1. Configure [object storage for Mattermost](https://docs.mattermost.com/administration/config-settings.html#file-storage) (optional feature).
@@ -2001,7 +2001,7 @@ based on what features you intend to use:
 1. Configure [object storage for Dependency Proxy](../packages/dependency_proxy.md#using-object-storage) (optional feature). **(PREMIUM ONLY)**
 1. Configure [object storage for Pseudonymizer](../pseudonymizer.md#configuration) (optional feature). **(ULTIMATE ONLY)**
 1. Configure [object storage for autoscale runner caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) (optional - for improved performance).
-1. Configure [object storage for Terraform state files](../terraform_state.md#using-object-storage-core-only).
+1. Configure [object storage for Terraform state files](../terraform_state.md#using-object-storage).
 
 Using separate buckets for each data type is the recommended approach for GitLab.
 

doc/administration/reference_architectures/1k_users.md

@@ -12,7 +12,7 @@ full list of reference architectures, see
 
 If you need to serve up to 1,000 users and you don't have strict availability
 requirements, a single-node solution with
-[frequent backups](index.md#automated-backups-core-only) is appropriate for
+[frequent backups](index.md#automated-backups) is appropriate for
 many organizations .
 
 > - **Supported users (approximate):** 1,000

doc/administration/reference_architectures/25k_users.md

@@ -1993,7 +1993,7 @@ based on what features you intend to use:
 1. Configure [object storage for job artifacts](../job_artifacts.md#using-object-storage)
    including [incremental logging](../job_logs.md#new-incremental-logging-architecture).
 1. Configure [object storage for LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage).
-1. Configure [object storage for uploads](../uploads.md#using-object-storage-core-only).
+1. Configure [object storage for uploads](../uploads.md#using-object-storage).
 1. Configure [object storage for merge request diffs](../merge_request_diffs.md#using-object-storage).
 1. Configure [object storage for Container Registry](../packages/container_registry.md#use-object-storage) (optional feature).
 1. Configure [object storage for Mattermost](https://docs.mattermost.com/administration/config-settings.html#file-storage) (optional feature).
@@ -2001,7 +2001,7 @@ based on what features you intend to use:
 1. Configure [object storage for Dependency Proxy](../packages/dependency_proxy.md#using-object-storage) (optional feature). **(PREMIUM ONLY)**
 1. Configure [object storage for Pseudonymizer](../pseudonymizer.md#configuration) (optional feature). **(ULTIMATE ONLY)**
 1. Configure [object storage for autoscale runner caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) (optional - for improved performance).
-1. Configure [object storage for Terraform state files](../terraform_state.md#using-object-storage-core-only).
+1. Configure [object storage for Terraform state files](../terraform_state.md#using-object-storage).
 
 Using separate buckets for each data type is the recommended approach for GitLab.
 

doc/administration/reference_architectures/2k_users.md

@@ -813,7 +813,7 @@ on the features you intend to use:
 1. [Object storage for job artifacts](../job_artifacts.md#using-object-storage)
    including [incremental logging](../job_logs.md#new-incremental-logging-architecture).
 1. [Object storage for LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage).
-1. [Object storage for uploads](../uploads.md#using-object-storage-core-only).
+1. [Object storage for uploads](../uploads.md#using-object-storage).
 1. [Object storage for merge request diffs](../merge_request_diffs.md#using-object-storage).
 1. [Object storage for Container Registry](../packages/container_registry.md#use-object-storage) (optional feature).
 1. [Object storage for Mattermost](https://docs.mattermost.com/administration/config-settings.html#file-storage) (optional feature).
@@ -821,7 +821,7 @@ on the features you intend to use:
 1. [Object storage for Dependency Proxy](../packages/dependency_proxy.md#using-object-storage) (optional feature). **(PREMIUM ONLY)**
 1. [Object storage for Pseudonymizer](../pseudonymizer.md#configuration) (optional feature). **(ULTIMATE ONLY)**
 1. [Object storage for autoscale runner caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) (optional, for improved performance).
-1. [Object storage for Terraform state files](../terraform_state.md#using-object-storage-core-only).
+1. [Object storage for Terraform state files](../terraform_state.md#using-object-storage).
 
 Using separate buckets for each data type is the recommended approach for GitLab.
 

doc/administration/reference_architectures/3k_users.md

@@ -1719,7 +1719,7 @@ based on what features you intend to use:
 1. Configure [object storage for job artifacts](../job_artifacts.md#using-object-storage)
    including [incremental logging](../job_logs.md#new-incremental-logging-architecture).
 1. Configure [object storage for LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage).
-1. Configure [object storage for uploads](../uploads.md#using-object-storage-core-only).
+1. Configure [object storage for uploads](../uploads.md#using-object-storage).
 1. Configure [object storage for merge request diffs](../merge_request_diffs.md#using-object-storage).
 1. Configure [object storage for Container Registry](../packages/container_registry.md#use-object-storage) (optional feature).
 1. Configure [object storage for Mattermost](https://docs.mattermost.com/administration/config-settings.html#file-storage) (optional feature).
@@ -1727,7 +1727,7 @@ based on what features you intend to use:
 1. Configure [object storage for Dependency Proxy](../packages/dependency_proxy.md#using-object-storage) (optional feature). **(PREMIUM ONLY)**
 1. Configure [object storage for Pseudonymizer](../pseudonymizer.md#configuration) (optional feature). **(ULTIMATE ONLY)**
 1. Configure [object storage for autoscale runner caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) (optional - for improved performance).
-1. Configure [object storage for Terraform state files](../terraform_state.md#using-object-storage-core-only).
+1. Configure [object storage for Terraform state files](../terraform_state.md#using-object-storage).
 
 Using separate buckets for each data type is the recommended approach for GitLab.
 

doc/administration/reference_architectures/50k_users.md

@@ -1993,7 +1993,7 @@ based on what features you intend to use:
 1. Configure [object storage for job artifacts](../job_artifacts.md#using-object-storage)
    including [incremental logging](../job_logs.md#new-incremental-logging-architecture).
 1. Configure [object storage for LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage).
-1. Configure [object storage for uploads](../uploads.md#using-object-storage-core-only).
+1. Configure [object storage for uploads](../uploads.md#using-object-storage).
 1. Configure [object storage for merge request diffs](../merge_request_diffs.md#using-object-storage).
 1. Configure [object storage for Container Registry](../packages/container_registry.md#use-object-storage) (optional feature).
 1. Configure [object storage for Mattermost](https://docs.mattermost.com/administration/config-settings.html#file-storage) (optional feature).
@@ -2001,7 +2001,7 @@ based on what features you intend to use:
 1. Configure [object storage for Dependency Proxy](../packages/dependency_proxy.md#using-object-storage) (optional feature). **(PREMIUM ONLY)**
 1. Configure [object storage for Pseudonymizer](../pseudonymizer.md#configuration) (optional feature). **(ULTIMATE ONLY)**
 1. Configure [object storage for autoscale runner caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) (optional - for improved performance).
-1. Configure [object storage for Terraform state files](../terraform_state.md#using-object-storage-core-only).
+1. Configure [object storage for Terraform state files](../terraform_state.md#using-object-storage).
 
 Using separate buckets for each data type is the recommended approach for GitLab.
 

doc/administration/reference_architectures/5k_users.md

@@ -1718,7 +1718,7 @@ based on what features you intend to use:
 1. Configure [object storage for job artifacts](../job_artifacts.md#using-object-storage)
    including [incremental logging](../job_logs.md#new-incremental-logging-architecture).
 1. Configure [object storage for LFS objects](../lfs/index.md#storing-lfs-objects-in-remote-object-storage).
-1. Configure [object storage for uploads](../uploads.md#using-object-storage-core-only).
+1. Configure [object storage for uploads](../uploads.md#using-object-storage).
 1. Configure [object storage for merge request diffs](../merge_request_diffs.md#using-object-storage).
 1. Configure [object storage for Container Registry](../packages/container_registry.md#use-object-storage) (optional feature).
 1. Configure [object storage for Mattermost](https://docs.mattermost.com/administration/config-settings.html#file-storage) (optional feature).
@@ -1726,7 +1726,7 @@ based on what features you intend to use:
 1. Configure [object storage for Dependency Proxy](../packages/dependency_proxy.md#using-object-storage) (optional feature). **(PREMIUM ONLY)**
 1. Configure [object storage for Pseudonymizer](../pseudonymizer.md#configuration) (optional feature). **(ULTIMATE ONLY)**
 1. Configure [object storage for autoscale runner caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) (optional - for improved performance).
-1. Configure [object storage for Terraform state files](../terraform_state.md#using-object-storage-core-only).
+1. Configure [object storage for Terraform state files](../terraform_state.md#using-object-storage).
 
 Using separate buckets for each data type is the recommended approach for GitLab.
 

doc/administration/reference_architectures/index.md

@@ -32,7 +32,7 @@ per 1,000 users:
 - Git: 2 RPS
 
 For GitLab instances with less than 2,000 users, it's recommended that you use
-the [default setup](#automated-backups-core-only) by
+the [default setup](#automated-backups) by
 [installing GitLab](../../install/README.md) on a single machine to minimize
 maintenance and resource costs.
 
@@ -73,11 +73,11 @@ The following reference architectures are available:
 GitLab comes with the following components for your use, listed from least to
 most complex:
 
-- [Automated backups](#automated-backups-core-only)
-- [Traffic load balancer](#traffic-load-balancer-starter-only)
-- [Zero downtime updates](#zero-downtime-updates-starter-only)
-- [Automated database failover](#automated-database-failover-premium-only)
-- [Instance level replication with GitLab Geo](#instance-level-replication-with-gitlab-geo-premium-only)
+- [Automated backups](#automated-backups)
+- [Traffic load balancer](#traffic-load-balancer)
+- [Zero downtime updates](#zero-downtime-updates)
+- [Automated database failover](#automated-database-failover)
+- [Instance level replication with GitLab Geo](#instance-level-replication-with-gitlab-geo)
 
 As you implement these components, begin with a single server and then do
 backups. Only after completing the first server should you proceed to the next.

doc/analytics/README.md

 ---
-redirect_to: '../user/group/index.md#user-contribution-analysis-starter'
+redirect_to: '../user/group/index.md#user-contribution-analysis'
 ---
 
-This document was moved to [another location](../user/group/index.md#user-contribution-analysis-starter)
+This document was moved to [another location](../user/group/index.md#user-contribution-analysis)

doc/api/audit_events.md

@@ -2,7 +2,7 @@
 
 ## Instance Audit Events **(PREMIUM ONLY)**
 
-The Audit Events API allows you to retrieve [instance audit events](../administration/audit_events.md#instance-events-premium-only).
+The Audit Events API allows you to retrieve [instance audit events](../administration/audit_events.md#instance-events).
 
 To retrieve audit events using the API, you must [authenticate yourself](README.md#authentication) as an Administrator.
 
@@ -124,7 +124,7 @@ Example response:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/34078) in GitLab 12.5.
 
-The Group Audit Events API allows you to retrieve [group audit events](../administration/audit_events.md#group-events-starter).
+The Group Audit Events API allows you to retrieve [group audit events](../administration/audit_events.md#group-events).
 
 To retrieve group audit events using the API, you must [authenticate yourself](README.md#authentication) as an Administrator or an owner of the group.
 
@@ -230,7 +230,7 @@ Example response:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/219238) in GitLab 13.1.
 
-The Project Audit Events API allows you to retrieve [project audit events](../administration/audit_events.md#project-events-starter).
+The Project Audit Events API allows you to retrieve [project audit events](../administration/audit_events.md#project-events).
 
 To retrieve project audit events using the API, you must [authenticate yourself](README.md#authentication) as a Maintainer or an Owner of the project.
 

doc/api/epic_links.md

@@ -2,7 +2,7 @@
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/9188) in GitLab 11.8.
 
-Manages parent-child [epic relationships](../user/group/epics/index.md#multi-level-child-epics-ultimate).
+Manages parent-child [epic relationships](../user/group/epics/index.md#multi-level-child-epics).
 
 Every API call to `epic_links` must be authenticated.
 

doc/api/groups.md

@@ -847,7 +847,7 @@ Only available to group owners and administrators.
 This endpoint either:
 
 - Removes group, and queues a background job to delete all projects in the group as well.
-- Since [GitLab 12.8](https://gitlab.com/gitlab-org/gitlab/-/issues/33257), on [Premium or Silver](https://about.gitlab.com/pricing/) or higher tiers, marks a group for deletion. The deletion will happen 7 days later by default, but this can be changed in the [instance settings](../user/admin_area/settings/visibility_and_access_controls.md#default-deletion-delay-premium-only).
+- Since [GitLab 12.8](https://gitlab.com/gitlab-org/gitlab/-/issues/33257), on [Premium or Silver](https://about.gitlab.com/pricing/) or higher tiers, marks a group for deletion. The deletion will happen 7 days later by default, but this can be changed in the [instance settings](../user/admin_area/settings/visibility_and_access_controls.md#default-deletion-delay).
 
 ```plaintext
 DELETE /groups/:id
@@ -1016,7 +1016,7 @@ DELETE /groups/:id/hooks/:hook_id
 
 ## Group Audit Events **(STARTER)**
 
-Group audit events can be accessed via the [Group Audit Events API](audit_events.md#group-audit-events-starter)
+Group audit events can be accessed via the [Group Audit Events API](audit_events.md#group-audit-events)
 
 ## Sync group with LDAP **(STARTER)**
 
@@ -1174,7 +1174,7 @@ DELETE /groups/:id/share/:group_id
 
 ### Get group push rules **(STARTER)**
 
-Get the [push rules](../user/group/index.md#group-push-rules-starter) of a group.
+Get the [push rules](../user/group/index.md#group-push-rules) of a group.
 
 Only available to group owners and administrators.
 
@@ -1217,7 +1217,7 @@ the `commit_committer_check` and `reject_unsigned_commits` parameters:
 
 ### Add group push rule **(STARTER)**
 
-Adds [push rules](../user/group/index.md#group-push-rules-starter) to the specified group.
+Adds [push rules](../user/group/index.md#group-push-rules) to the specified group.
 
 Only available to group owners and administrators.
 
@@ -1311,7 +1311,7 @@ Response:
 
 ### Delete group push rule **(STARTER)**
 
-Deletes the [push rules](../user/group/index.md#group-push-rules-starter) of a group.
+Deletes the [push rules](../user/group/index.md#group-push-rules) of a group.
 
 Only available to group owners and administrators.
 

doc/api/job_artifacts.md

@@ -14,7 +14,7 @@ GET /projects/:id/jobs/:job_id/artifacts
 |-------------|----------------|----------|-------------------------------------------------------------------------------------------------------------------------------------------------|
 | `id`        | integer/string | yes      | ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user.                                |
 | `job_id`    | integer        | yes      | ID of a job.                                                                                                                                |
-| `job_token` **(PREMIUM)** | string         | no       | To be used with [triggers](../ci/triggers/README.md#when-a-pipeline-depends-on-the-artifacts-of-another-pipeline-premium) for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
+| `job_token` **(PREMIUM)** | string         | no       | To be used with [triggers](../ci/triggers/README.md#when-a-pipeline-depends-on-the-artifacts-of-another-pipeline) for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
 
 Example request using the `PRIVATE-TOKEN` header:
 
@@ -74,7 +74,7 @@ Parameters
 | `id`        | integer/string | yes      | ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user.                                |
 | `ref_name`  | string         | yes      | Branch or tag name in repository. HEAD or SHA references are not supported.                                                                     |
 | `job`       | string         | yes      | The name of the job.                                                                                                                            |
-| `job_token` **(PREMIUM)** | string         | no       | To be used with [triggers](../ci/triggers/README.md#when-a-pipeline-depends-on-the-artifacts-of-another-pipeline-premium) for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
+| `job_token` **(PREMIUM)** | string         | no       | To be used with [triggers](../ci/triggers/README.md#when-a-pipeline-depends-on-the-artifacts-of-another-pipeline) for multi-project pipelines. It should be invoked only inside `.gitlab-ci.yml`. Its value is always `$CI_JOB_TOKEN`. |
 
 Example request using the `PRIVATE-TOKEN` header:
 

doc/api/project_templates.md

@@ -21,7 +21,7 @@ It deprecates these endpoints, which will be removed for API version 5.
 In addition to templates common to the entire instance, project-specific
 templates are also available from this API endpoint.
 
-Support for [Group-level file templates](../user/group/index.md#group-file-templates-premium)
+Support for [Group-level file templates](../user/group/index.md#group-file-templates)
 **(PREMIUM)** was [added](https://gitlab.com/gitlab-org/gitlab/-/issues/5987)
 in GitLab 11.5
 

doc/api/projects.md

@@ -1839,15 +1839,15 @@ This endpoint:
 
 - Deletes a project including all associated resources (issues, merge requests etc).
 - From [GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/issues/220382) on [Premium or Silver](https://about.gitlab.com/pricing/) or higher tiers,
-group admins can [configure](../user/group/index.md#enabling-delayed-project-removal-premium) projects within a group
+group admins can [configure](../user/group/index.md#enabling-delayed-project-removal) projects within a group
 to be deleted after a delayed period.
 When enabled, actual deletion happens after the number of days
-specified in the [default deletion delay](../user/admin_area/settings/visibility_and_access_controls.md#default-deletion-delay-premium-only).
+specified in the [default deletion delay](../user/admin_area/settings/visibility_and_access_controls.md#default-deletion-delay).
 
 CAUTION: **Warning:**
 The default behavior of [Delayed Project deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/32935) in GitLab 12.6
 was changed to [Immediate deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/220382)
-in GitLab 13.2, as discussed in [Enabling delayed project removal](../user/group/index.md#enabling-delayed-project-removal-premium).
+in GitLab 13.2, as discussed in [Enabling delayed project removal](../user/group/index.md#enabling-delayed-project-removal).
 
 ```plaintext
 DELETE /projects/:id

doc/api/protected_branches.md

@@ -255,7 +255,7 @@ Example response:
 ### Example with user / group level access **(STARTER)**
 
 Elements in the `allowed_to_push` / `allowed_to_merge` / `allowed_to_unprotect` array should take the
-form `{user_id: integer}`, `{group_id: integer}` or `{access_level: integer}`. Each user must have access to the project and each group must [have this project shared](../user/project/members/share_project_with_groups.md). These access levels allow [more granular control over protected branch access](../user/project/protected_branches.md#restricting-push-and-merge-access-to-certain-users-starter) and were [added to the API](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3516) in GitLab 10.3 EE.
+form `{user_id: integer}`, `{group_id: integer}` or `{access_level: integer}`. Each user must have access to the project and each group must [have this project shared](../user/project/members/share_project_with_groups.md). These access levels allow [more granular control over protected branch access](../user/project/protected_branches.md#restricting-push-and-merge-access-to-certain-users) and were [added to the API](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3516) in GitLab 10.3 EE.
 
 ```shell
 curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/5/protected_branches?name=*-stable&allowed_to_push%5B%5D%5Buser_id%5D=1"

doc/api/remote_mirrors.md

@@ -7,7 +7,7 @@ type: reference, api
 
 # Project remote mirrors API
 
-[Push mirrors](../user/project/repository/repository_mirroring.md#pushing-to-a-remote-repository-core)
+[Push mirrors](../user/project/repository/repository_mirroring.md#pushing-to-a-remote-repository)
 defined on a project's repository settings are called "remote mirrors", and the
 state of these mirrors can be queried and modified via the remote mirror API
 outlined below.

doc/api/users.md

@@ -820,7 +820,7 @@ Parameters:
 - `expires_at` (optional) - The expiration date of the SSH key in ISO 8601 format (`YYYY-MM-DDTHH:MM:SSZ`)
 
 NOTE: **Note:**
-This also adds an audit event, as described in [audit instance events](../administration/audit_events.md#instance-events-premium-only). **(PREMIUM)**
+This also adds an audit event, as described in [audit instance events](../administration/audit_events.md#instance-events). **(PREMIUM)**
 
 ## Delete SSH key for current user
 

doc/api/visual_review_discussions.md

@@ -10,7 +10,7 @@ type: reference, api
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/18710) in [GitLab Starter](https://about.gitlab.com/pricing/) 12.5.
 
 Visual Review discussions are notes on Merge Requests sent as
-feedback from [Visual Reviews](../ci/review_apps/index.md#visual-reviews-starter).
+feedback from [Visual Reviews](../ci/review_apps/index.md#visual-reviews).
 
 ## Create new merge request thread
 

doc/ci/ci_cd_for_external_repos/bitbucket_integration.md

@@ -19,7 +19,7 @@ To use GitLab CI/CD with a Bitbucket Cloud repository:
 
    ![Create project](img/external_repository.png)
 
-   GitLab will import the repository and enable [Pull Mirroring](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository-starter).
+   GitLab will import the repository and enable [Pull Mirroring](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository).
 
 1. In GitLab create a
    [Personal Access Token](../../user/profile/personal_access_tokens.md)

doc/ci/ci_cd_for_external_repos/github_integration.md

@@ -47,7 +47,7 @@ repositories:
 GitLab will:
 
 1. Import the project.
-1. Enable [Pull Mirroring](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository-starter)
+1. Enable [Pull Mirroring](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository)
 1. Enable [GitHub project integration](../../user/project/integrations/github.md)
 1. Create a web hook on GitHub to notify GitLab of new commits.
 
@@ -85,7 +85,7 @@ To manually enable GitLab CI/CD for your repository:
    new commits.
 
    The web hook URL should be set to the GitLab API to
-   [trigger pull mirroring](../../api/projects.md#start-the-pull-mirroring-process-for-a-project-starter),
+   [trigger pull mirroring](../../api/projects.md#start-the-pull-mirroring-process-for-a-project),
    using the GitLab personal access token we just created:
 
    ```plaintext

doc/ci/directed_acyclic_graph/index.md

@@ -86,7 +86,7 @@ are certain use cases that you may need to work around. For more information:
 > - It became [enabled by default](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36802) in 13.2.
 > - It became a [standard feature](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38517) in 13.3.
 > - It's enabled on GitLab.com.
-> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-dag-visualization-core-only).
+> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-dag-visualization).
 
 The DAG visualization makes it easier to visualize the relationships between dependent jobs in a DAG. This graph will display all the jobs in a pipeline that need or are needed by other jobs. Jobs with no relationships are not displayed in this view.
 

doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md

@@ -66,7 +66,7 @@ unresolved state or your pipelines may be dropped.
 
 ## Using Merge Trains
 
-When you enable [Pipelines for merged results](#pipelines-for-merged-results-premium),
+When you enable [Pipelines for merged results](#pipelines-for-merged-results),
 GitLab [automatically displays](merge_trains/index.md#add-a-merge-request-to-a-merge-train)
 a **Start/Add Merge Train button**.
 

doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md

@@ -13,7 +13,7 @@ last_update: 2019-07-03
 
 For more information about why you might want to use Merge Trains, read [How merge trains keep your master green](https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-trains/).
 
-When [pipelines for merged results](../index.md#pipelines-for-merged-results-premium) are
+When [pipelines for merged results](../index.md#pipelines-for-merged-results) are
 enabled, the pipeline jobs run as if the changes from your source branch have already
 been merged into the target branch.
 
@@ -80,7 +80,7 @@ To enable merge trains:
 
 To enable merge trains for your project:
 
-1. If you are on a self-managed GitLab instance, ensure the [feature flag](#merge-trains-feature-flag-premium-only) is set correctly.
+1. If you are on a self-managed GitLab instance, ensure the [feature flag](#merge-trains-feature-flag) is set correctly.
 1. [Configure your CI/CD configuration file](../../index.md#configuring-pipelines-for-merge-requests)
    so that the pipeline or individual jobs run for merge requests.
 1. Visit your project's **Settings > General** and expand **Merge requests**.

doc/ci/metrics_reports.md

@@ -37,7 +37,7 @@ All values are considered strings and string compare is used to find differences
 
 ## How to set it up
 
-Add a job that creates a [metrics report](pipelines/job_artifacts.md#artifactsreportsmetrics-premium) (default filename: `metrics.txt`). The file should conform to the [OpenMetrics](https://openmetrics.io/) format.
+Add a job that creates a [metrics report](pipelines/job_artifacts.md#artifactsreportsmetrics) (default filename: `metrics.txt`). The file should conform to the [OpenMetrics](https://openmetrics.io/) format.
 
 For example:
 

doc/ci/migration/jenkins.md

@@ -107,7 +107,7 @@ There are some high level differences between the products worth mentioning:
   is in the YAML format (see [complete reference](../yaml/README.md)) instead of a Groovy DSL. It's most
   analogous to the declarative Jenkinsfile format.
 - Manual approvals or gates can be set up as [`when:manual` jobs](../yaml/README.md#whenmanual). These can
-  also leverage [`protected environments`](../yaml/README.md#protecting-manual-jobs-premium)
+  also leverage [`protected environments`](../yaml/README.md#protecting-manual-jobs)
   to control who is able to approve them.
 - GitLab comes with a [container registry](../../user/packages/container_registry/index.md), and we recommend using
   container images to set up your build environment. For example, set up one pipeline that builds your build environment

doc/ci/pipelines/index.md

@@ -40,7 +40,7 @@ A typical pipeline might consist of four stages, executed in the following order
 - A `production` stage, with a job called `deploy-to-prod`.
 
 NOTE: **Note:**
-If you have a [mirrored repository that GitLab pulls from](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository-starter),
+If you have a [mirrored repository that GitLab pulls from](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository),
 you may need to enable pipeline triggering in your project's
 **Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates**.
 
@@ -483,7 +483,7 @@ be found when you are on a [single pipeline page](#view-pipelines). For example:
 
 ![Pipelines example](img/pipelines.png)
 
-[Multi-project pipeline graphs](../multi_project_pipelines.md#multi-project-pipeline-visualization-premium) help
+[Multi-project pipeline graphs](../multi_project_pipelines.md#multi-project-pipeline-visualization) help
 you visualize the entire pipeline, including all cross-project inter-dependencies. **(PREMIUM)**
 
 ### Pipeline mini graphs

doc/ci/pipelines/job_artifacts.md

@@ -47,7 +47,7 @@ when the job fails, or always, by using [`artifacts:when`](../yaml/README.md#art
 parameter. GitLab keeps these uploaded artifacts for 1 week, as defined
 by the `expire_in` definition. You can keep the artifacts from expiring
 via the [web interface](#browsing-artifacts). If the expiry time is not defined, it defaults
-to the [instance wide setting](../../user/admin_area/settings/continuous_integration.md#default-artifacts-expiration-core-only).
+to the [instance wide setting](../../user/admin_area/settings/continuous_integration.md#default-artifacts-expiration).
 
 For more examples on artifacts, follow the [artifacts reference in
 `.gitlab-ci.yml`](../yaml/README.md#artifacts).
@@ -221,7 +221,7 @@ dashboards.
 
 CAUTION: **Warning:**
 This artifact is still valid but is **deprecated** in favor of the
-[artifacts:reports:license_scanning](../pipelines/job_artifacts.md#artifactsreportslicense_scanning-ultimate)
+[artifacts:reports:license_scanning](../pipelines/job_artifacts.md#artifactsreportslicense_scanning)
 introduced in GitLab 12.8.
 
 The `license_management` report collects [Licenses](../../user/compliance/license_compliance/index.md)

doc/ci/pipelines/settings.md

@@ -67,7 +67,7 @@ Project defined timeout (either specific timeout set by user or the default
 ## Maximum artifacts size **(CORE ONLY)**
 
 For information about setting a maximum artifact size for a project, see
-[Maximum artifacts size](../../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size-core-only).
+[Maximum artifacts size](../../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size).
 
 ## Custom CI configuration path
 

doc/ci/quick_start/README.md

@@ -135,7 +135,7 @@ Now if you go to the **Pipelines** page you will see that the pipeline is
 pending.
 
 NOTE: **Note:**
-If you have a [mirrored repository where GitLab pulls from](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository-starter),
+If you have a [mirrored repository where GitLab pulls from](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository),
 you may need to enable pipeline triggering in your project's
 **Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates**.
 

doc/ci/runners/README.md

@@ -45,7 +45,7 @@ If you are using a self-managed instance of GitLab:
   <!-- **Settings > CI / CD**, expanding the **Runners** section, and clicking **Show runner installation instructions**.-->
   <!-- These instructions are also available [here](https://docs.gitlab.com/runner/install/index.html).-->
 - The administrator can also configure a maximum number of shared runner [pipeline minutes for
-  each group](../../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota-starter-only).
+  each group](../../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota).
 
 If you are using GitLab.com:
 

doc/ci/unit_test_reports.md

@@ -258,7 +258,7 @@ You can also retrieve the reports via the [GitLab API](../api/pipelines.md#get-a
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/202114) in GitLab 13.0.
 > - It's deployed behind a feature flag, disabled by default.
-> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enabling-the-junit-screenshots-feature-core-only). **(CORE ONLY)**
+> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enabling-the-junit-screenshots-feature). **(CORE ONLY)**
 
 If JUnit report format XML files contain an `attachment` tag, GitLab parses the attachment.
 

doc/ci/variables/README.md

@@ -149,7 +149,7 @@ Malicious code pushed to your `.gitlab-ci.yml` file could compromise your variab
 
 All merge requests that introduce changes to `.gitlab-ci.yml` should be reviewed carefully before:
 
-- [Running a pipeline in the parent project for a merge request submitted from a forked project](../merge_request_pipelines/index.md#run-pipelines-in-the-parent-project-for-merge-requests-from-a-forked-project-starter).
+- [Running a pipeline in the parent project for a merge request submitted from a forked project](../merge_request_pipelines/index.md#run-pipelines-in-the-parent-project-for-merge-requests-from-a-forked-project).
 - Merging the changes.
 
 Here is a simplified example of a malicious `.gitlab-ci.yml`:
@@ -766,7 +766,7 @@ so `&&` is evaluated before `||`.
 > - It's deployed behind a feature flag, enabled by default.
 > - It's enabled on GitLab.com.
 > - It's recommended for production use.
-> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-parenthesis-support-for-variables-core-only). **(CORE ONLY)**
+> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-parenthesis-support-for-variables). **(CORE ONLY)**
 
 It is possible to use parentheses to group conditions. Parentheses have the highest
 precedence of all operators. Expressions enclosed in parentheses are evaluated first,

doc/ci/yaml/README.md

@@ -34,8 +34,9 @@ We have complete examples of configuring pipelines:
 >   from 30 days to under 8 hours with GitLab.
 
 NOTE: **Note:**
-If you have a [mirrored repository that GitLab pulls from](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository-starter),
+If you have a [mirrored repository that GitLab pulls from](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository),
 you may need to enable pipeline triggering. Go to your project's
+
 **Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates**.
 
 ## Introduction
@@ -363,7 +364,7 @@ makes your pipelines run for branches and tags.
 Branch pipeline status will be displayed within merge requests that use that branch
 as a source, but this pipeline type does not support any features offered by
 [Merge Request Pipelines](../merge_request_pipelines/) like
-[Pipelines for Merge Results](../merge_request_pipelines/#pipelines-for-merged-results-premium)
+[Pipelines for Merge Results](../merge_request_pipelines/#pipelines-for-merged-results)
 or [Merge Trains](../merge_request_pipelines/pipelines_for_merged_results/merge_trains/).
 Use this template if you are intentionally avoiding those features.
 
@@ -2076,7 +2077,9 @@ This example creates four paths of execution:
 - The maximum number of jobs that a single job can need in the `needs:` array is limited:
   - For GitLab.com, the limit is 50. For more information, see our
     [infrastructure issue](https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/7541).
-  - For self-managed instances, the limit is: 50. This limit [can be changed](#changing-the-needs-job-limit-core-only).
+  - For self-managed instances, the limit is:
+    - 10, if the `ci_plan_needs_size_limit` feature flag is disabled (default).
+    - 50, if the `ci_plan_needs_size_limit` feature flag is enabled. This limit [can be changed](#changing-the-needs-job-limit).
 - If `needs:` refers to a job that is marked as `parallel:`.
   the current job will depend on all parallel jobs created.
 - `needs:` is similar to `dependencies:` in that it needs to use jobs from prior stages,
@@ -2391,7 +2394,7 @@ Manual actions are considered to be write actions, so permissions for
 a user wants to trigger an action. In other words, in order to trigger a manual
 action assigned to a branch that the pipeline is running for, the user needs to
 have the ability to merge to this branch. It's possible to use protected environments
-to more strictly [protect manual deployments](#protecting-manual-jobs-premium) from being
+to more strictly [protect manual deployments](#protecting-manual-jobs) from being
 run by unauthorized users.
 
 NOTE: **Note:**
@@ -3255,7 +3258,7 @@ expire and are deleted.
 
 The expiration time period begins when the artifact is uploaded and
 stored on GitLab. If the expiry time is not defined, it defaults to the
-[instance wide setting](../../user/admin_area/settings/continuous_integration.md#default-artifacts-expiration-core-only)
+[instance wide setting](../../user/admin_area/settings/continuous_integration.md#default-artifacts-expiration)
 (30 days by default).
 
 To override the expiration date and protect artifacts from being automatically deleted:
@@ -3306,17 +3309,17 @@ These are the available report types:
 |--------------------------------------------------------------------------------------------------------------------------------------|-------------|
 | [`artifacts:reports:cobertura`](../pipelines/job_artifacts.md#artifactsreportscobertura)                                             | The `cobertura` report collects Cobertura coverage XML files.                    |
 | [`artifacts:reports:codequality`](../pipelines/job_artifacts.md#artifactsreportscodequality)                                         | The `codequality` report collects CodeQuality issues.                            |
-| [`artifacts:reports:container_scanning`](../pipelines/job_artifacts.md#artifactsreportscontainer_scanning-ultimate) **(ULTIMATE)**   | The `container_scanning` report collects Container Scanning vulnerabilities.     |
-| [`artifacts:reports:dast`](../pipelines/job_artifacts.md#artifactsreportsdast-ultimate) **(ULTIMATE)**                               | The `dast` report collects Dynamic Application Security Testing vulnerabilities. |
-| [`artifacts:reports:dependency_scanning`](../pipelines/job_artifacts.md#artifactsreportsdependency_scanning-ultimate) **(ULTIMATE)** | The `dependency_scanning` report collects Dependency Scanning vulnerabilities.   |
+| [`artifacts:reports:container_scanning`](../pipelines/job_artifacts.md#artifactsreportscontainer_scanning) **(ULTIMATE)**   | The `container_scanning` report collects Container Scanning vulnerabilities.     |
+| [`artifacts:reports:dast`](../pipelines/job_artifacts.md#artifactsreportsdast) **(ULTIMATE)**                               | The `dast` report collects Dynamic Application Security Testing vulnerabilities. |
+| [`artifacts:reports:dependency_scanning`](../pipelines/job_artifacts.md#artifactsreportsdependency_scanning) **(ULTIMATE)** | The `dependency_scanning` report collects Dependency Scanning vulnerabilities.   |
 | [`artifacts:reports:dotenv`](../pipelines/job_artifacts.md#artifactsreportsdotenv)                                                   | The `dotenv` report collects a set of environment variables.                     |
 | [`artifacts:reports:junit`](../pipelines/job_artifacts.md#artifactsreportsjunit)                                                     | The `junit` report collects JUnit XML files.                                     |
-| [`artifacts:reports:license_management`](../pipelines/job_artifacts.md#artifactsreportslicense_management-ultimate) **(ULTIMATE)**   | The `license_management` report collects Licenses (*removed from GitLab 13.0*).  |
-| [`artifacts:reports:license_scanning`](../pipelines/job_artifacts.md#artifactsreportslicense_scanning-ultimate) **(ULTIMATE)**       | The `license_scanning` report collects Licenses.                                 |
-| [`artifacts:reports:load_performance`](../pipelines/job_artifacts.md#artifactsreportsload_performance-premium) **(PREMIUM)**         | The `load_performance` report collects load performance metrics.                 |
-| [`artifacts:reports:metrics`](../pipelines/job_artifacts.md#artifactsreportsmetrics-premium) **(PREMIUM)**                           | The `metrics` report collects Metrics.                                           |
-| [`artifacts:reports:performance`](../pipelines/job_artifacts.md#artifactsreportsperformance-premium) **(PREMIUM)**                   | The `performance` report collects Browser Performance metrics.                   |
-| [`artifacts:reports:sast`](../pipelines/job_artifacts.md#artifactsreportssast-ultimate) **(ULTIMATE)**                               | The `sast` report collects Static Application Security Testing vulnerabilities.  |
+| [`artifacts:reports:license_management`](../pipelines/job_artifacts.md#artifactsreportslicense_management) **(ULTIMATE)**   | The `license_management` report collects Licenses (*removed from GitLab 13.0*).  |
+| [`artifacts:reports:license_scanning`](../pipelines/job_artifacts.md#artifactsreportslicense_scanning) **(ULTIMATE)**       | The `license_scanning` report collects Licenses.                                 |
+| [`artifacts:reports:load_performance`](../pipelines/job_artifacts.md#artifactsreportsload_performance) **(PREMIUM)**         | The `load_performance` report collects load performance metrics.                 |
+| [`artifacts:reports:metrics`](../pipelines/job_artifacts.md#artifactsreportsmetrics) **(PREMIUM)**                           | The `metrics` report collects Metrics.                                           |
+| [`artifacts:reports:performance`](../pipelines/job_artifacts.md#artifactsreportsperformance) **(PREMIUM)**                   | The `performance` report collects Browser Performance metrics.                   |
+| [`artifacts:reports:sast`](../pipelines/job_artifacts.md#artifactsreportssast) **(ULTIMATE)**                               | The `sast` report collects Static Application Security Testing vulnerabilities.  |
 | [`artifacts:reports:terraform`](../pipelines/job_artifacts.md#artifactsreportsterraform)                                             | The `terraform` report collects Terraform `tfplan.json` files.                   |
 
 #### `dependencies`

doc/development/approval_rules.md

@@ -81,7 +81,7 @@ The `ApprovalState` model get these records when approval rules are not
 overwritten.
 
 The `protected_branches` attribute is set and used when a rule is scoped to
-protected branches. See [Scoped to Protected Branch doc](../user/project/merge_requests/merge_request_approvals.md#scoped-to-protected-branch-premium)
+protected branches. See [Scoped to Protected Branch doc](../user/project/merge_requests/merge_request_approvals.md#scoped-to-protected-branch)
 for more information about the feature.
 
 ### `ApprovalMergeRequestRule`

doc/development/cicd/index.md

@@ -25,7 +25,7 @@ On the left side we have the events that can trigger a pipeline based on various
 - The [Web API](../../api/pipelines.md#create-a-new-pipeline).
 - A user clicking the "Run Pipeline" button in the UI.
 - When a [merge request is created or updated](../../ci/merge_request_pipelines/index.md#pipelines-for-merge-requests).
-- When an MR is added to a [Merge Train](../../ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md#merge-trains-premium).
+- When an MR is added to a [Merge Train](../../ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md#merge-trains).
 - A [scheduled pipeline](../../ci/pipelines/schedules.md#pipeline-schedules).
 - When project is [subscribed to an upstream project](../../ci/multi_project_pipelines.md#trigger-a-pipeline-when-an-upstream-project-is-rebuilt).
 - When [Auto DevOps](../../topics/autodevops/index.md) is enabled.

doc/development/code_review.md

@@ -358,10 +358,10 @@ When ready to merge:
   messy commit history that is intended to be squashed.
 - **Start a new merge request pipeline with the `Run Pipeline` button in the merge
   request's "Pipelines" tab, and enable "Merge When Pipeline Succeeds" (MWPS).** Note that:
-  - If the **latest [Pipeline for Merged Results](../ci/merge_request_pipelines/pipelines_for_merged_results/#pipelines-for-merged-results-premium)** finished less than 2 hours ago, you
+  - If the **latest [Pipeline for Merged Results](../ci/merge_request_pipelines/pipelines_for_merged_results/#pipelines-for-merged-results)** finished less than 2 hours ago, you
     might merge without starting a new pipeline as the merge request is close
     enough to `master`.
-  - If the **merge request is from a fork**, we can use [Pipelines for Merged Results from a forked project](../ci/merge_request_pipelines/index.md#run-pipelines-in-the-parent-project-for-merge-requests-from-a-forked-project-starter) with caution.
+  - If the **merge request is from a fork**, we can use [Pipelines for Merged Results from a forked project](../ci/merge_request_pipelines/index.md#run-pipelines-in-the-parent-project-for-merge-requests-from-a-forked-project) with caution.
     Before triggering the pipeline, review all changes for **malicious code**.
     If you cannot trigger the pipeline, review the status of the fork relative to `master`.
     If it's more than 100 commits behind, ask the author to rebase it before merging.

doc/development/contributing/issue_workflow.md

@@ -118,7 +118,7 @@ the `gitlab-org` group since its key under `stages` is `manage`.
 
 The current stage labels can be found by [searching the labels list for `devops::`](https://gitlab.com/groups/gitlab-org/-/labels?search=devops::).
 
-These labels are [scoped labels](../../user/project/labels.md#scoped-labels-premium)
+These labels are [scoped labels](../../user/project/labels.md#scoped-labels)
 and thus are mutually exclusive.
 
 The Stage labels are used to generate the [direction pages](https://about.gitlab.com/direction/) automatically.
@@ -145,7 +145,7 @@ under `stages.manage.groups` is `continuous_integration`.
 
 The current group labels can be found by [searching the labels list for `group::`](https://gitlab.com/groups/gitlab-org/-/labels?search=group::).
 
-These labels are [scoped labels](../../user/project/labels.md#scoped-labels-premium)
+These labels are [scoped labels](../../user/project/labels.md#scoped-labels)
 and thus are mutually exclusive.
 
 You can find the groups listed in the [Product Stages, Groups, and Categories](https://about.gitlab.com/handbook/product/product-categories/) page.

doc/development/documentation/workflow.md

@@ -29,7 +29,7 @@ is added or updated. The following are added by the issue or merge request autho
 
 The following are also added by members of the Technical Writing team:
 
-- A documentation [scoped label](../../user/project/labels.md#scoped-labels-premium) with the
+- A documentation [scoped label](../../user/project/labels.md#scoped-labels) with the
   `docs::` prefix. For example, `~docs::improvement`.
 - The `~Technical Writing` [team label](../contributing/issue_workflow.md#team-labels).
 

doc/development/elasticsearch.md

@@ -218,7 +218,7 @@ logs will also include the time spent on Database and Gitaly requests, which
 may help to diagnose which part of the search is performing poorly.
 
 There are additional logs specific to Elasticsearch that are sent to
-[`elasticsearch.log`](../administration/logs.md#elasticsearchlog-starter-only)
+[`elasticsearch.log`](../administration/logs.md#elasticsearchlog)
 that may contain information to help diagnose performance issues.
 
 ### Performance Bar

doc/development/integrations/secure_partner_integration.md

@@ -37,14 +37,14 @@ best place to integrate your own product and its results into GitLab.
   implications for app security, corporate policy, or compliance. When complete,
   the job reports back on its status and creates a
   [job artifact](../../user/project/pipelines/job_artifacts.md) as a result.
-- The [Merge Request Security Widget](../../user/project/merge_requests/testing_and_reports_in_merge_requests.md#security-reports-ultimate)
+- The [Merge Request Security Widget](../../user/project/merge_requests/testing_and_reports_in_merge_requests.md#security-reports)
   displays the results of the pipeline's security checks and the developer can
   review them. The developer can review both a summary and a detailed version
   of the results.
 - If certain policies (such as [merge request approvals](../../user/project/merge_requests/merge_request_approvals.md))
   are in place for a project, developers must resolve specific findings or get
   an approval from a specific list of people.
-- The [security dashboard](../../user/application_security/security_dashboard/index.md#gitlab-security-dashboard-ultimate)
+- The [security dashboard](../../user/application_security/security_dashboard/index.md#gitlab-security-dashboard)
   also shows results which can developers can use to quickly see all the
   vulnerabilities that need to be addressed in the code.
 - When the developer reads the details about a vulnerability, they are
@@ -88,7 +88,7 @@ and complete an integration with the Secure stage.
      - If you need a new kind of scan or report, [create an issue](https://gitlab.com/gitlab-org/gitlab/-/issues/new#)
        and add the label `devops::secure`.
    - Once the job is completed, the data can be seen:
-      - In the [Merge Request Security Report](../../user/project/merge_requests/testing_and_reports_in_merge_requests.md#security-reports-ultimate) ([MR Security Report data flow](https://gitlab.com/snippets/1910005#merge-request-view)).
+      - In the [Merge Request Security Report](../../user/project/merge_requests/testing_and_reports_in_merge_requests.md#security-reports) ([MR Security Report data flow](https://gitlab.com/snippets/1910005#merge-request-view)).
       - While [browsing a Job Artifact](../../user/project/pipelines/job_artifacts.md).
       - In the [Security Dashboard](../../user/application_security/security_dashboard/index.md) ([Dashboard data flow](https://gitlab.com/snippets/1910005#project-and-group-dashboards)).
 1. Optional: Provide a way to interact with results as Vulnerabilities:

doc/development/repository_mirroring.md

@@ -3,7 +3,7 @@
 ## Deep Dive
 
 In December 2018, Tiago Botelho hosted a Deep Dive (GitLab team members only: `https://gitlab.com/gitlab-org/create-stage/issues/1`)
-on GitLab's [Pull Repository Mirroring functionality](../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository-starter)
+on GitLab's [Pull Repository Mirroring functionality](../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository)
 to share his domain specific knowledge with anyone who may work in this part of the
 code base in the future. You can find the [recording on YouTube](https://www.youtube.com/watch?v=sSZq0fpdY-Y),
 and the slides in [PDF](https://gitlab.com/gitlab-org/create-stage/uploads/8693404888a941fd851f8a8ecdec9675/Gitlab_Create_-_Pull_Mirroring_Deep_Dive.pdf).

doc/getting-started/subscription.md

 ---
 redirect_to: '../subscriptions/index.md'
----
+---
\ No newline at end of file

doc/gitlab-basics/create-project.md

@@ -63,7 +63,7 @@ There are two types of project templates:
 - [Built-in templates](#built-in-templates), sourced from the following groups:
   - [`project-templates`](https://gitlab.com/gitlab-org/project-templates)
   - [`pages`](https://gitlab.com/pages)
-- [Custom project templates](#custom-project-templates-premium), for custom templates
+- [Custom project templates](#custom-project-templates), for custom templates
   configured by GitLab administrators and users.
 
 #### Built-in templates

doc/install/azure/index.md

@@ -419,7 +419,7 @@ Check out our other [Technical Articles](../../articles/index.md) or browse the
 ### Useful links
 
 - [GitLab Community Edition](https://about.gitlab.com/features/)
-- [GitLab Enterprise Edition](https://about.gitlab.com/features/#ee-starter)
+- [GitLab Enterprise Edition](https://about.gitlab.com/features/#ee)
 - [Microsoft Azure](https://azure.microsoft.com/en-us/)
   - [Azure - Free Account FAQ](https://azure.microsoft.com/en-us/free/free-account-faq/)
   - [Azure - Marketplace](https://azuremarketplace.microsoft.com/en-us/marketplace/)

doc/integration/kerberos.md

@@ -103,7 +103,7 @@ enabled, then your users will be automatically linked to their LDAP accounts on
 first login. For this to work, some prerequisites must be met:
 
 The Kerberos username must match the LDAP user's UID. You can choose which LDAP
-attribute is used as the UID in GitLab's [LDAP configuration](../administration/auth/ldap/index.md#configuration-core-only)
+attribute is used as the UID in GitLab's [LDAP configuration](../administration/auth/ldap/index.md#configuration)
 but for Active Directory, this should be `sAMAccountName`.
 
 The Kerberos realm must match the domain part of the LDAP user's Distinguished

doc/operations/incident_management/incidents.md

@@ -57,7 +57,7 @@ to create issues when alerts are triggered:
    checkbox to create an issue based on your own
    [issue templates](../../user/project/description_templates.md#creating-issue-templates).
    For more information, see
-   [Trigger actions from alerts](../metrics/alerts.md#trigger-actions-from-alerts-ultimate) **(ULTIMATE)**.
+   [Trigger actions from alerts](../metrics/alerts.md#trigger-actions-from-alerts) **(ULTIMATE)**.
 1. To create issues from alerts, select the template in the **Issue Template**
    select box.
 1. To send [separate email notifications](index.md#notify-developers-of-alerts) to users
@@ -68,7 +68,7 @@ to create issues when alerts are triggered:
 Appropriately configured alerts include an
 [embedded chart](../metrics/embed.md#embedding-metrics-based-on-alerts-in-incident-issues)
 for the query corresponding to the alert. You can also configure GitLab to
-[close issues](../metrics/alerts.md#trigger-actions-from-alerts-ultimate)
+[close issues](../metrics/alerts.md#trigger-actions-from-alerts)
 when you receive notification that the alert is resolved.
 
 ## Create an incident manually

doc/operations/index.md

@@ -36,7 +36,7 @@ Are your alerts too noisy? Alerts configured on GitLab metrics can configured
 and fine-tuned in GitLab immediately following a fire-fight.
 
 - [Manage alerts and incidents](../user/incident_management/index.md) in GitLab.
-- [Configure alerts for metrics](metrics/alerts.md#set-up-alerts-for-prometheus-metrics-core) in GitLab.
+- [Configure alerts for metrics](metrics/alerts.md#set-up-alerts-for-prometheus-metrics) in GitLab.
 - Create a [status page](incident_management/status_page.md)
   to communicate efficiently to your users during an incident.
 

doc/operations/metrics/alerts.md

@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 After [configuring metrics for your CI/CD environment](index.md), you can set up
 alerting for Prometheus metrics depending on the location of your instances, and
-[trigger actions from alerts](#trigger-actions-from-alerts-ultimate) to notify
+[trigger actions from alerts](#trigger-actions-from-alerts) to notify
 your team when environment performance falls outside of the boundaries you set.
 
 ## Managed Prometheus instances

doc/operations/metrics/index.md

@@ -118,7 +118,7 @@ After creating your dashboard, you can customize it to meet your needs:
   [create custom metrics](#adding-custom-metrics) and display them on your metrics dashboard.
 - **Configure alerts for metrics**: [Configure custom alerts](alerts.md) for your team when
   environment performance falls outside of the boundaries you set.
-- **Trigger actions from alerts**: [Open new issues for your team](alerts.md#trigger-actions-from-alerts-ultimate) **(ULTIMATE)**
+- **Trigger actions from alerts**: [Open new issues for your team](alerts.md#trigger-actions-from-alerts) **(ULTIMATE)**
   when environment performance falls outside of the boundaries you set.
 
 ## Metrics dashboard visibility

doc/push_rules/push_rules.md

@@ -78,7 +78,7 @@ See [server hooks](../administration/server_hooks.md) for more information.
 NOTE: **Note:**
 GitLab administrators can set push rules globally under
 **Admin Area > Push Rules** that all new projects will inherit. You can later
-override them in a project's settings. They can be also set on a [group level](../user/group/index.md#group-push-rules-starter).
+override them in a project's settings. They can be also set on a [group level](../user/group/index.md#group-push-rules).
 
 1. Navigate to your project's **Settings > Repository** and expand **Push Rules**
 1. Set the rule you want

doc/topics/application_development_platform/index.md

@@ -47,10 +47,10 @@ that may lead to security problems and unintended use. This can be achieved by m
 which inform security teams and developers if there is something to consider changing in their apps
 before it is too late to create a preventative fix. The following features are included:
 
-- [Auto SAST (Static Application Security Testing)](../autodevops/stages.md#auto-sast-ultimate)
-- [Auto Dependency Scanning](../autodevops/stages.md#auto-dependency-scanning-ultimate)
-- [Auto Container Scanning](../autodevops/stages.md#auto-container-scanning-ultimate)
-- [Auto DAST (Dynamic Application Security Testing)](../autodevops/stages.md#auto-dast-ultimate)
+- [Auto SAST (Static Application Security Testing)](../autodevops/stages.md#auto-sast)
+- [Auto Dependency Scanning](../autodevops/stages.md#auto-dependency-scanning)
+- [Auto Container Scanning](../autodevops/stages.md#auto-container-scanning)
+- [Auto DAST (Dynamic Application Security Testing)](../autodevops/stages.md#auto-dast)
 
 ### Observability
 

doc/topics/autodevops/customize.md

@@ -325,14 +325,14 @@ applications.
 | `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. [More details](upgrading_chart.md#ignore-warning-and-continue-deploying) |
 | `AUTO_DEVOPS_MODSECURITY_SEC_RULE_ENGINE` | From GitLab 12.5, used in combination with [ModSecurity feature flag](../../user/clusters/applications.md#web-application-firewall-modsecurity) to toggle [ModSecurity's `SecRuleEngine`](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)#SecRuleEngine) behavior. Defaults to `DetectionOnly`. |
 | `BUILDPACK_URL`                         | Buildpack's full URL. Can point to either [a Git repository URL or a tarball URL](#custom-buildpacks). |
-| `CANARY_ENABLED`                        | From GitLab 11.0, used to define a [deploy policy for canary environments](#deploy-policy-for-canary-environments-premium). |
+| `CANARY_ENABLED`                        | From GitLab 11.0, used to define a [deploy policy for canary environments](#deploy-policy-for-canary-environments). |
 | `CANARY_PRODUCTION_REPLICAS`            | Number of canary replicas to deploy for [Canary Deployments](../../user/project/canary_deployments.md) in the production environment. Takes precedence over `CANARY_REPLICAS`. Defaults to 1. |
 | `CANARY_REPLICAS`                       | Number of canary replicas to deploy for [Canary Deployments](../../user/project/canary_deployments.md). Defaults to 1. |
 | `DOCKERFILE_PATH`                       | From GitLab 13.2, allows overriding the [default Dockerfile path for the build stage](#custom-dockerfile) |
 | `HELM_RELEASE_NAME`                     | From GitLab 12.1, allows the `helm` release name to be overridden. Can be used to assign unique release names when deploying multiple projects to a single namespace. |
 | `HELM_UPGRADE_VALUES_FILE`              | From GitLab 12.6, allows the `helm upgrade` values file to be overridden. Defaults to `.gitlab/auto-deploy-values.yaml`. |
 | `HELM_UPGRADE_EXTRA_ARGS`               | From GitLab 11.11, allows extra arguments in `helm` commands when deploying the application. Note that using quotes won't prevent word splitting. |
-| `INCREMENTAL_ROLLOUT_MODE`              | From GitLab 11.4, if present, can be used to enable an [incremental rollout](#incremental-rollout-to-production-premium) of your application for the production environment. Set to `manual` for manual deployment jobs or `timed` for automatic rollout deployments with a 5 minute delay each one. |
+| `INCREMENTAL_ROLLOUT_MODE`              | From GitLab 11.4, if present, can be used to enable an [incremental rollout](#incremental-rollout-to-production) of your application for the production environment. Set to `manual` for manual deployment jobs or `timed` for automatic rollout deployments with a 5 minute delay each one. |
 | `K8S_SECRET_*`                          | From GitLab 11.7, any variable prefixed with [`K8S_SECRET_`](#application-secret-variables) will be made available by Auto DevOps as environment variables to the deployed application. |
 | `KUBE_INGRESS_BASE_DOMAIN`              | From GitLab 11.8, can be used to set a domain per cluster. See [cluster domains](../../user/project/clusters/index.md#base-domain) for more information. |
 | `PRODUCTION_REPLICAS`                   | Number of replicas to deploy in the production environment. Takes precedence over `REPLICAS` and defaults to 1. For zero downtime upgrades, set to 2 or greater. |
@@ -585,7 +585,7 @@ TIP: **Tip:**
 You can also set this inside your [project's settings](index.md#deployment-strategy).
 
 This configuration is based on
-[incremental rollout to production](#incremental-rollout-to-production-premium).
+[incremental rollout to production](#incremental-rollout-to-production).
 
 Everything behaves the same way, except:
 

doc/topics/autodevops/index.md

@@ -33,7 +33,7 @@ For requirements, see [Requirements for Auto DevOps](requirements.md) for more i
 
 Auto DevOps is enabled by default for all projects and attempts to run on all pipelines
 in each project. An instance administrator can enable or disable this default in the
-[Auto DevOps settings](../../user/admin_area/settings/continuous_integration.md#auto-devops-core-only).
+[Auto DevOps settings](../../user/admin_area/settings/continuous_integration.md#auto-devops).
 Auto DevOps automatically disables in individual projects on their first pipeline failure,
 if it has not been explicitly enabled for the project.
 
@@ -83,16 +83,16 @@ project in a simple and automatic way:
 
 1. [Auto Build](stages.md#auto-build)
 1. [Auto Test](stages.md#auto-test)
-1. [Auto Code Quality](stages.md#auto-code-quality-starter) **(STARTER)**
-1. [Auto SAST (Static Application Security Testing)](stages.md#auto-sast-ultimate) **(ULTIMATE)**
-1. [Auto Secret Detection](stages.md#auto-secret-detection-ultimate) **(ULTIMATE)**
-1. [Auto Dependency Scanning](stages.md#auto-dependency-scanning-ultimate) **(ULTIMATE)**
-1. [Auto License Compliance](stages.md#auto-license-compliance-ultimate) **(ULTIMATE)**
-1. [Auto Container Scanning](stages.md#auto-container-scanning-ultimate) **(ULTIMATE)**
+1. [Auto Code Quality](stages.md#auto-code-quality) **(STARTER)**
+1. [Auto SAST (Static Application Security Testing)](stages.md#auto-sast) **(ULTIMATE)**
+1. [Auto Secret Detection](stages.md#auto-secret-detection) **(ULTIMATE)**
+1. [Auto Dependency Scanning](stages.md#auto-dependency-scanning) **(ULTIMATE)**
+1. [Auto License Compliance](stages.md#auto-license-compliance) **(ULTIMATE)**
+1. [Auto Container Scanning](stages.md#auto-container-scanning) **(ULTIMATE)**
 1. [Auto Review Apps](stages.md#auto-review-apps)
-1. [Auto DAST (Dynamic Application Security Testing)](stages.md#auto-dast-ultimate) **(ULTIMATE)**
+1. [Auto DAST (Dynamic Application Security Testing)](stages.md#auto-dast) **(ULTIMATE)**
 1. [Auto Deploy](stages.md#auto-deploy)
-1. [Auto Browser Performance Testing](stages.md#auto-browser-performance-testing-premium) **(PREMIUM)**
+1. [Auto Browser Performance Testing](stages.md#auto-browser-performance-testing) **(PREMIUM)**
 1. [Auto Monitoring](stages.md#auto-monitoring)
 
 As Auto DevOps relies on many different components, you should have a basic
@@ -235,12 +235,12 @@ are available:
 - **Continuous deployment to production**: Enables [Auto Deploy](stages.md#auto-deploy)
   with `master` branch directly deployed to production.
 - **Continuous deployment to production using timed incremental rollout**: Sets the
-  [`INCREMENTAL_ROLLOUT_MODE`](customize.md#timed-incremental-rollout-to-production-premium) variable
+  [`INCREMENTAL_ROLLOUT_MODE`](customize.md#timed-incremental-rollout-to-production) variable
   to `timed`. Production deployments execute with a 5 minute delay between
   each increment in rollout.
 - **Automatic deployment to staging, manual deployment to production**: Sets the
   [`STAGING_ENABLED`](customize.md#deploy-policy-for-staging-and-production-environments) and
-  [`INCREMENTAL_ROLLOUT_MODE`](customize.md#incremental-rollout-to-production-premium) variables
+  [`INCREMENTAL_ROLLOUT_MODE`](customize.md#incremental-rollout-to-production) variables
   to `1` and `manual`. This means:
 
   - `master` branch is directly deployed to staging.
@@ -274,7 +274,7 @@ The following table is an example of how to configure the three different cluste
 |--------------|---------------------------|-------------------------------------------|----------------------------|---|
 | review       | `review/*`                | `review.example.com`                      | `review/*`                 | The review cluster which runs all [Review Apps](../../ci/review_apps/index.md). `*` is a wildcard, used by every environment name starting with `review/`. |
 | staging      | `staging`                 | `staging.example.com`                     | `staging`                  | (Optional) The staging cluster which runs the deployments of the staging environments. You must [enable it first](customize.md#deploy-policy-for-staging-and-production-environments). |
-| production   | `production`              | `example.com`                             | `production`               | The production cluster which runs the production environment deployments. You can use [incremental rollouts](customize.md#incremental-rollout-to-production-premium). |
+| production   | `production`              | `example.com`                             | `production`               | The production cluster which runs the production environment deployments. You can use [incremental rollouts](customize.md#incremental-rollout-to-production). |
 
 To add a different cluster for each environment:
 

doc/topics/autodevops/quick_start_guide.md

@@ -160,18 +160,18 @@ The jobs are separated into stages:
   - The `test` job runs unit and integration tests by detecting the language and
     framework ([Auto Test](stages.md#auto-test))
   - The `code_quality` job checks the code quality and is allowed to fail
-    ([Auto Code Quality](stages.md#auto-code-quality-starter)) **(STARTER)**
+    ([Auto Code Quality](stages.md#auto-code-quality)) **(STARTER)**
   - The `container_scanning` job checks the Docker container if it has any
-    vulnerabilities and is allowed to fail ([Auto Container Scanning](stages.md#auto-container-scanning-ultimate))
+    vulnerabilities and is allowed to fail ([Auto Container Scanning](stages.md#auto-container-scanning))
   - The `dependency_scanning` job checks if the application has any dependencies
     susceptible to vulnerabilities and is allowed to fail
-    ([Auto Dependency Scanning](stages.md#auto-dependency-scanning-ultimate)) **(ULTIMATE)**
+    ([Auto Dependency Scanning](stages.md#auto-dependency-scanning)) **(ULTIMATE)**
   - Jobs suffixed with `-sast` run static analysis on the current code to check for potential
-    security issues, and are allowed to fail ([Auto SAST](stages.md#auto-sast-ultimate)) **(ULTIMATE)**
-  - The `secret-detection` job checks for leaked secrets and is allowed to fail ([Auto Secret Detection](stages.md#auto-secret-detection-ultimate)) **(ULTIMATE)**
+    security issues, and are allowed to fail ([Auto SAST](stages.md#auto-sast)) **(ULTIMATE)**
+  - The `secret-detection` job checks for leaked secrets and is allowed to fail ([Auto Secret Detection](stages.md#auto-secret-detection)) **(ULTIMATE)**
   - The `license_management` job searches the application's dependencies to determine each of their
     licenses and is allowed to fail
-    ([Auto License Compliance](stages.md#auto-license-compliance-ultimate)) **(ULTIMATE)**
+    ([Auto License Compliance](stages.md#auto-license-compliance)) **(ULTIMATE)**
 
    NOTE: **Note:**
    All jobs except `test` are allowed to fail in the test stage.
@@ -183,7 +183,7 @@ The jobs are separated into stages:
   Kubernetes ([Auto Deploy](stages.md#auto-deploy)).
 
 - **Performance** - Performance tests are run on the deployed application
-  ([Auto Browser Performance Testing](stages.md#auto-browser-performance-testing-premium)). **(PREMIUM)**
+  ([Auto Browser Performance Testing](stages.md#auto-browser-performance-testing)). **(PREMIUM)**
 
 - **Cleanup** - Pipelines on `master` include this stage with a `stop_dast_environment` job.
 
@@ -292,7 +292,7 @@ and customized to fit your workflow. Here are some helpful resources for further
 
 1. [Auto DevOps](index.md)
 1. [Multiple Kubernetes clusters](index.md#using-multiple-kubernetes-clusters)
-1. [Incremental rollout to production](customize.md#incremental-rollout-to-production-premium) **(PREMIUM)**
+1. [Incremental rollout to production](customize.md#incremental-rollout-to-production) **(PREMIUM)**
 1. [Disable jobs you don't need with environment variables](customize.md#environment-variables)
 1. [Use a static IP for your cluster](../../user/clusters/applications.md#using-a-static-ip)
 1. [Use your own buildpacks to build your application](customize.md#custom-buildpacks)

doc/user/admin_area/analytics/dev_ops_report.md

@@ -4,7 +4,7 @@
 > - [Renamed from Conversational Development Index](https://gitlab.com/gitlab-org/gitlab/-/issues/20976) in GitLab 12.6.
 
 NOTE: **Note:**
-Your GitLab instance's [usage ping](../settings/usage_statistics.md#usage-ping-core-only) must be activated in order to use this feature.
+Your GitLab instance's [usage ping](../settings/usage_statistics.md#usage-ping) must be activated in order to use this feature.
 
 The DevOps Report gives you an overview of your entire instance's adoption of
 [Concurrent DevOps](https://about.gitlab.com/topics/concurrent-devops/)
@@ -15,7 +15,7 @@ from planning to monitoring.
 DevOps Score displays the usage of GitLab's major features on your instance over
 the last 30 days, averaged over the number of active users in that time period. It also
 provides a Lead score per feature, which is calculated based on GitLab's analysis
-of top-performing instances based on [usage ping data](../settings/usage_statistics.md#usage-ping-core-only) that GitLab has
+of top-performing instances based on [usage ping data](../settings/usage_statistics.md#usage-ping) that GitLab has
 collected. Your score is compared to the lead score of each feature and then expressed as a percentage at the bottom of said feature.
 Your overall **DevOps Score** is an average of your feature scores. You can use this score to compare your DevOps status to other organizations.
 

doc/user/admin_area/index.md

@@ -21,7 +21,7 @@ The Admin Area is made up of the following sections:
 | Section                                        | Description                                                                                                                                                                                                                                                                              |
 |:-----------------------------------------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | **{overview}** [Overview](#overview-section)   | View your GitLab [Dashboard](#admin-dashboard), and administer [projects](#administering-projects), [users](#administering-users), [groups](#administering-groups), [jobs](#administering-jobs), [Runners](#administering-runners), and [Gitaly servers](#administering-gitaly-servers). |
-| **{monitor}** Monitoring                       | View GitLab [system information](#system-info), and information on [background jobs](#background-jobs), [logs](#logs), [health checks](monitoring/health_check.md), [requests profiles](#requests-profiles), and [audit logs](#audit-log-premium-only).                                  |
+| **{monitor}** Monitoring                       | View GitLab [system information](#system-info), and information on [background jobs](#background-jobs), [logs](#logs), [health checks](monitoring/health_check.md), [requests profiles](#requests-profiles), and [audit logs](#audit-log).                                  |
 | **{messages}** Messages                        | Send and manage [broadcast messages](broadcast_messages.md) for your users.                                                                                                                                                                                                              |
 | **{hook}** System Hooks                        | Configure [system hooks](../../system_hooks/system_hooks.md) for many events.                                                                                                                                                                                                            |
 | **{applications}** Applications                | Create system [OAuth applications](../../integration/oauth_provider.md) for integrations with other services.                                                                                                                                                                            |

doc/user/admin_area/settings/account_and_limit_settings.md

@@ -137,7 +137,7 @@ Once a lifetime for personal access tokens is set, GitLab will:
 > - It is deployed behind a feature flag, disabled by default.
 > - It is disabled on GitLab.com.
 > - It is not recommended for production use.
-> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-optional-enforcement-of-personal-access-token-expiry-feature-core-only). **(CORE ONLY)**
+> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-optional-enforcement-of-personal-access-token-expiry-feature). **(CORE ONLY)**
 
 GitLab administrators can choose to prevent personal access tokens from expiring automatically. The tokens will be usable after the expiry date, unless they are revoked explicitly.
 

doc/user/admin_area/settings/index.md

@@ -42,7 +42,7 @@ Access the default page for admin area settings by navigating to **Admin Area >
 
 | Option | Description |
 | ------ | ----------- |
-| [Repository's custom initial branch name](../../project/repository/branches/index.md#custom-initial-branch-name-core-only) | Set a custom branch name rather than master for all the new repositories created within your instance. |
+| [Repository's custom initial branch name](../../project/repository/branches/index.md#custom-initial-branch-name) | Set a custom branch name rather than master for all the new repositories created within your instance. |
 | [Repository mirror](visibility_and_access_controls.md#allow-mirrors-to-be-set-up-for-projects) | Configure repository mirroring. |
 | [Repository storage](../../../administration/repository_storage_types.md) | Configure storage path settings. |
 | Repository maintenance | ([Repository checks](../../../administration/repository_checks.md) and [Housekeeping](../../../administration/housekeeping.md)). Configure automatic Git checks and housekeeping on repositories. |
@@ -60,8 +60,8 @@ Access the default page for admin area settings by navigating to **Admin Area >
 | Option | Description |
 | ------ | ----------- |
 | [Continuous Integration and Deployment](continuous_integration.md) | Auto DevOps, runners and job artifacts. |
-| [Required pipeline configuration](continuous_integration.md#required-pipeline-configuration-premium-only) **(PREMIUM ONLY)** | Set an instance-wide auto included [pipeline configuration](../../../ci/yaml/README.md). This pipeline configuration will be run after the project's own configuration. |
-| [Package Registry](continuous_integration.md#package-registry-configuration-premium-only) | Settings related to the use and experience of using GitLab's Package Registry. Note there are [risks involved](./../../packages/container_registry/index.md#use-with-external-container-registries) in enabling some of these settings. |
+| [Required pipeline configuration](continuous_integration.md#required-pipeline-configuration) **(PREMIUM ONLY)** | Set an instance-wide auto included [pipeline configuration](../../../ci/yaml/README.md). This pipeline configuration will be run after the project's own configuration. |
+| [Package Registry](continuous_integration.md#package-registry-configuration) | Settings related to the use and experience of using GitLab's Package Registry. Note there are [risks involved](./../../packages/container_registry/index.md#use-with-external-container-registries) in enabling some of these settings. |
 
 ## Reporting
 
@@ -106,7 +106,7 @@ Access the default page for admin area settings by navigating to **Admin Area >
 | [Pages](../../../administration/pages/index.md#custom-domain-verification) | Size and domain settings for static websites |
 | [Real-time features](../../../administration/polling.md) | Change this value to influence how frequently the GitLab UI polls for updates. |
 | [Gitaly timeouts](gitaly_timeouts.md) | Configure Gitaly timeouts. |
-| Localization | [Default first day of the week](../../profile/preferences.md) and [Time tracking](../../project/time_tracking.md#limit-displayed-units-to-hours-core-only). |
+| Localization | [Default first day of the week](../../profile/preferences.md) and [Time tracking](../../project/time_tracking.md#limit-displayed-units-to-hours). |
 
 NOTE: **Note:**
 You can change the [Default first day of the week](../../profile/preferences.md) for the entire GitLab instance

doc/user/admin_area/settings/visibility_and_access_controls.md

@@ -78,7 +78,7 @@ CAUTION: **Warning:**
 The default behavior of [Delayed Project deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/32935) in GitLab 12.6 was changed to
 [Immediate deletion](https://gitlab.com/gitlab-org/gitlab/-/issues/220382) in GitLab 13.2.
 
-Projects within a group can be deleted after a delayed period, by [configuring in Group Settings](../../group/index.md#enabling-delayed-project-removal-premium).
+Projects within a group can be deleted after a delayed period, by [configuring in Group Settings](../../group/index.md#enabling-delayed-project-removal).
 
 The default period is 7 days, and can be changed. Setting this period to 0 will enable immediate removal
 of projects or groups.
@@ -92,7 +92,7 @@ To change this period:
 
 Alternatively, projects that are marked for removal can be deleted immediately. To do so:
 
-1. [Restore the project](../../project/settings/#restore-a-project-premium).
+1. [Restore the project](../../project/settings/#restore-a-project).
 1. Delete the project as described in the [Administering Projects page](../../admin_area/#administering-projects).
 
 ## Default project visibility

doc/user/analytics/value_stream_analytics.md

@@ -267,7 +267,7 @@ Once a custom stage has been added, you can "drag and drop" stages to rearrange
 The pre-defined start and end events can cover many use cases involving both issues and merge requests.
 
 For supporting more complex workflows, use stages based on group labels. These events are based on
-labels being added or removed. In particular, [scoped labels](../project/labels.md#scoped-labels-premium)
+labels being added or removed. In particular, [scoped labels](../project/labels.md#scoped-labels)
 are useful for complex workflows.
 
 In this example, we'd like to measure more accurate code review times. The workflow is the following:

doc/user/application_security/container_scanning/index.md

@@ -26,7 +26,7 @@ To integrate security scanners other than Clair and Klar into GitLab, see
 You can enable container scanning by doing one of the following:
 
 - [Include the CI job](#configuration) in your existing `.gitlab-ci.yml` file.
-- Implicitly use [Auto Container Scanning](../../../topics/autodevops/stages.md#auto-container-scanning-ultimate)
+- Implicitly use [Auto Container Scanning](../../../topics/autodevops/stages.md#auto-container-scanning)
   provided by [Auto DevOps](../../../topics/autodevops/index.md).
 
 GitLab compares the found vulnerabilities between the source and target branches, and shows the
@@ -95,7 +95,7 @@ The included template:
   (see [requirements](#requirements)) and scans it for possible vulnerabilities.
 
 GitLab saves the results as a
-[Container Scanning report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportscontainer_scanning-ultimate)
+[Container Scanning report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportscontainer_scanning)
 that you can download and analyze later. When downloading, you always receive the most-recent
 artifact.
 

doc/user/application_security/dast/index.md

@@ -26,7 +26,7 @@ If you're using [GitLab CI/CD](../../../ci/README.md), you can analyze your runn
 for known vulnerabilities using Dynamic Application Security Testing (DAST).
 You can take advantage of DAST by either [including the CI job](#configuration) in
 your existing `.gitlab-ci.yml` file or by implicitly using
-[Auto DAST](../../../topics/autodevops/stages.md#auto-dast-ultimate),
+[Auto DAST](../../../topics/autodevops/stages.md#auto-dast),
 provided by [Auto DevOps](../../../topics/autodevops/index.md).
 
 GitLab checks the DAST report, compares the found vulnerabilities between the source and target
@@ -106,7 +106,7 @@ The included template creates a `dast` job in your CI/CD pipeline and scans
 your project's source code for possible vulnerabilities.
 
 The results are saved as a
-[DAST report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsdast-ultimate)
+[DAST report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsdast)
 that you can later download and analyze. Due to implementation limitations we
 always take the latest DAST artifact available. Behind the scenes, the
 [GitLab DAST Docker image](https://gitlab.com/gitlab-org/security-products/dast)
@@ -183,7 +183,7 @@ variables:
 ```
 
 The results are saved as a
-[DAST report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsdast-ultimate)
+[DAST report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsdast)
 that you can later download and analyze.
 Due to implementation limitations, we always take the latest DAST artifact available.
 

doc/user/application_security/dependency_scanning/index.md

@@ -20,7 +20,7 @@ vulnerabilities using Dependency Scanning.
 All dependencies are scanned, including the transitive dependencies (also known as nested dependencies).
 You can take advantage of Dependency Scanning by either [including the Dependency Scanning template](#configuration)
 in your existing `.gitlab-ci.yml` file or by implicitly using
-the [Auto Dependency Scanning](../../../topics/autodevops/stages.md#auto-dependency-scanning-ultimate)
+the [Auto Dependency Scanning](../../../topics/autodevops/stages.md#auto-dependency-scanning)
 provided by [Auto DevOps](../../../topics/autodevops/index.md).
 
 GitLab checks the Dependency Scanning report, compares the found vulnerabilities
@@ -100,7 +100,7 @@ include:
 The included template creates Dependency Scanning jobs in your CI/CD
 pipeline and scans your project's source code for possible vulnerabilities.
 The results are saved as a
-[Dependency Scanning report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsdependency_scanning-ultimate)
+[Dependency Scanning report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsdependency_scanning)
 that you can later download and analyze. Due to implementation limitations, we
 always take the latest Dependency Scanning artifact available.
 

doc/user/application_security/index.md

@@ -77,12 +77,12 @@ GitLab uses the following tools to scan and report known vulnerabilities found i
 
 When [Auto DevOps](../../topics/autodevops/) is enabled, all GitLab Security scanning tools will be configured using default settings.
 
-- [Auto SAST](../../topics/autodevops/stages.md#auto-sast-ultimate)
-- [Auto Secret Detection](../../topics/autodevops/stages.md#auto-secret-detection-ultimate)
-- [Auto DAST](../../topics/autodevops/stages.md#auto-dast-ultimate)
-- [Auto Dependency Scanning](../../topics/autodevops/stages.md#auto-dependency-scanning-ultimate)
-- [Auto License Compliance](../../topics/autodevops/stages.md#auto-license-compliance-ultimate)
-- [Auto Container Scanning](../../topics/autodevops/stages.md#auto-container-scanning-ultimate)
+- [Auto SAST](../../topics/autodevops/stages.md#auto-sast)
+- [Auto Secret Detection](../../topics/autodevops/stages.md#auto-secret-detection)
+- [Auto DAST](../../topics/autodevops/stages.md#auto-dast)
+- [Auto Dependency Scanning](../../topics/autodevops/stages.md#auto-dependency-scanning)
+- [Auto License Compliance](../../topics/autodevops/stages.md#auto-license-compliance)
+- [Auto Container Scanning](../../topics/autodevops/stages.md#auto-container-scanning)
 
 While you cannot directly customize Auto DevOps, you can [include the Auto DevOps template in your project's `.gitlab-ci.yml` file](../../topics/autodevops/customize.md#customizing-gitlab-ciyml).
 

doc/user/application_security/sast/index.md

@@ -48,7 +48,7 @@ To run SAST jobs, by default, you need a GitLab Runner with the
 [`kubernetes`](https://docs.gitlab.com/runner/install/kubernetes.html) executor.
 If you're using the shared Runners on GitLab.com, this is enabled by default.
 
-Beginning with GitLab 13.0, Docker privileged mode is necessary only if you've [enabled Docker-in-Docker for SAST](#enabling-docker-in-docker-ultimate).
+Beginning with GitLab 13.0, Docker privileged mode is necessary only if you've [enabled Docker-in-Docker for SAST](#enabling-docker-in-docker).
 
 CAUTION: **Caution:**
 Our SAST jobs require a Linux container type. Windows containers are not yet supported.
@@ -95,7 +95,7 @@ All open source (OSS) analyzers have been moved to the GitLab Core tier. Progres
 tracked in the corresponding
 [epic](https://gitlab.com/groups/gitlab-org/-/epics/2098).
 
-Please note that support for [Docker-in-Docker](#enabling-docker-in-docker-ultimate)
+Please note that support for [Docker-in-Docker](#enabling-docker-in-docker)
 will not be extended to the GitLab Core tier.
 
 #### Summary of features per tier
@@ -109,8 +109,8 @@ as shown in the following table:
 | [Customize SAST Settings](#customizing-the-sast-settings)                          | **{check-circle}**  | **{check-circle}** |
 | View [JSON Report](#reports-json-format)                                           | **{check-circle}**  | **{check-circle}** |
 | [Presentation of JSON Report in Merge Request](#overview)                          | **{dotted-circle}** | **{check-circle}** |
-| [Interaction with Vulnerabilities](#interacting-with-the-vulnerabilities-ultimate) | **{dotted-circle}** | **{check-circle}** |
-| [Access to Security Dashboard](#security-dashboard-ultimate)                       | **{dotted-circle}** | **{check-circle}** |
+| [Interaction with Vulnerabilities](#interacting-with-the-vulnerabilities) | **{dotted-circle}** | **{check-circle}** |
+| [Access to Security Dashboard](#security-dashboard)                       | **{dotted-circle}** | **{check-circle}** |
 
 ## Contribute your scanner
 
@@ -120,7 +120,7 @@ The [Security Scanner Integration](../../../development/integrations/secure.md)
 
 To configure SAST for a project you can:
 
-- Use [Auto SAST](../../../topics/autodevops/stages.md#auto-sast-ultimate) provided by
+- Use [Auto SAST](../../../topics/autodevops/stages.md#auto-sast) provided by
   [Auto DevOps](../../../topics/autodevops/index.md).
 - [Configure SAST manually](#configure-sast-manually).
 - [Configure SAST using the UI](#configure-sast-in-the-ui) (introduced in GitLab 13.3).
@@ -143,7 +143,7 @@ The included template creates SAST jobs in your CI/CD pipeline and scans
 your project's source code for possible vulnerabilities.
 
 The results are saved as a
-[SAST report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportssast-ultimate)
+[SAST report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportssast)
 that you can later download and analyze. Due to implementation limitations, we
 always take the latest SAST artifact available.
 
@@ -329,7 +329,7 @@ The following are Docker image-related variables.
 | `SECURE_ANALYZERS_PREFIX` | Override the name of the Docker registry providing the default images (proxy). Read more about [customizing analyzers](analyzers.md). |
 | `SAST_ANALYZER_IMAGE_TAG` | **DEPRECATED:** Override the Docker tag of the default images. Read more about [customizing analyzers](analyzers.md).                 |
 | `SAST_DEFAULT_ANALYZERS`  | Override the names of default images. Read more about [customizing analyzers](analyzers.md).                                          |
-| `SAST_DISABLE_DIND`       | Disable Docker-in-Docker and run analyzers [individually](#enabling-docker-in-docker-ultimate). This variable is `true` by default.   |
+| `SAST_DISABLE_DIND`       | Disable Docker-in-Docker and run analyzers [individually](#enabling-docker-in-docker). This variable is `true` by default.   |
 
 #### Vulnerability filters
 
@@ -346,7 +346,7 @@ Some analyzers make it possible to filter out vulnerabilities under a given thre
 
 #### Docker-in-Docker orchestrator
 
-The following variables configure the Docker-in-Docker orchestrator, and therefore are only used when the Docker-in-Docker mode is [enabled](#enabling-docker-in-docker-ultimate).
+The following variables configure the Docker-in-Docker orchestrator, and therefore are only used when the Docker-in-Docker mode is [enabled](#enabling-docker-in-docker).
 
 | Environment variable                     | Default value | Description                                                                                                                                                                                                                                              |
 |------------------------------------------|---------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|

doc/user/application_security/secret_detection/index.md

@@ -83,7 +83,7 @@ variable. For example, `https://username:$password@example.com/path/to/repo` won
 detected, whereas `https://username:password@example.com/path/to/repo` would be detected.
 
 NOTE: **Note:**
-You don't have to configure Secret Detection manually as shown in this section if you're using [Auto Secret Detection](../../../topics/autodevops/stages.md#auto-secret-detection-ultimate)
+You don't have to configure Secret Detection manually as shown in this section if you're using [Auto Secret Detection](../../../topics/autodevops/stages.md#auto-secret-detection)
 provided by [Auto DevOps](../../../topics/autodevops/index.md).
 
 To enable Secret Detection for GitLab 13.1 and later, you must include the `Secret-Detection.gitlab-ci.yml` template that’s provided as a part of your GitLab installation. For GitLab versions earlier than 11.9, you can copy and use the job as defined in that template.
@@ -99,7 +99,7 @@ The included template creates Secret Detection jobs in your CI/CD pipeline and s
 your project's source code for secrets.
 
 The results are saved as a
-[Secret Detection report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportssecret_detection-ultimate)
+[Secret Detection report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportssecret_detection)
 that you can later download and analyze. Due to implementation limitations, we
 always take the latest Secret Detection artifact available.
 

doc/user/compliance/license_compliance/index.md

@@ -16,7 +16,7 @@ is incompatible with yours, then you can deny the use of that license.
 
 You can take advantage of License Compliance by either [including the job](#configuration)
 in your existing `.gitlab-ci.yml` file or by implicitly using
-[Auto License Compliance](../../../topics/autodevops/stages.md#auto-license-compliance-ultimate)
+[Auto License Compliance](../../../topics/autodevops/stages.md#auto-license-compliance)
 that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
 
 GitLab checks the License Compliance report, compares the licenses between the
@@ -118,7 +118,7 @@ the `license_management` job, so you must migrate to the `license_scanning` job
 `License-Scanning.gitlab-ci.yml` template.
 
 The results will be saved as a
-[License Compliance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportslicense_scanning-ultimate)
+[License Compliance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportslicense_scanning)
 that you can later download and analyze. Due to implementation limitations, we
 always take the latest License Compliance artifact available. Behind the scenes, the
 [GitLab License Compliance Docker image](https://gitlab.com/gitlab-org/security-products/license-management)

doc/user/discussions/index.md

@@ -501,7 +501,7 @@ introduced by [#25381](https://gitlab.com/gitlab-org/gitlab/-/issues/25381).
 > - It was deployed behind a feature flag, disabled by default.
 > - [Became enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/227799) on GitLab 13.2.
 > - It's enabled on GitLab.com.
-> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-batch-suggestions-core-only).
+> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-batch-suggestions).
 
 You can apply multiple suggestions at once to reduce the number of commits added
 to your branch to address your reviewers' requests.

doc/user/gitlab_com/index.md

@@ -87,7 +87,7 @@ Below are the current settings regarding [GitLab CI/CD](../../ci/README.md).
 | [Max CI/CD subscriptions to a project](../../administration/instance_limits.md#number-of-cicd-subscriptions-to-a-project) | `2` | Unlimited |
 | [Max pipeline schedules in projects](../../administration/instance_limits.md#number-of-pipeline-schedules) | `10` for Free tier, `50` for all paid tiers | Unlimited |
 | [Max number of instance level variables](../../administration/instance_limits.md#number-of-instance-level-variables) | `25` | `25` |
-| [Scheduled Job Archival](../../user/admin_area/settings/continuous_integration.md#archive-jobs-core-only) | 3 months | Never |
+| [Scheduled Job Archival](../../user/admin_area/settings/continuous_integration.md#archive-jobs) | 3 months | Never |
 
 ## Repository size limit
 
@@ -259,7 +259,7 @@ The Windows Shared Runners are currently in
 for production workloads.
 
 During the beta period, the
-[shared runner pipeline quota](../admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota-starter-only)
+[shared runner pipeline quota](../admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota)
 will apply for groups and projects in the same way as Linux Runners.
 This may change when the beta period ends, as discussed in this
 [related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/30834).