diff options
| author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-09-07 18:09:04 +0300 |
|---|---|---|
| committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-09-07 18:09:04 +0300 |
| commit | cf24d183b3f71f091a02f12b211f3001be5b5085 (patch) | |
| tree | f39e5c05483b1f9a2a34d06e52de52750ef5b08e /doc | |
| parent | a8653790086d284cecffdc35892bb422cd6c9a7b (diff) | |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc')
122 files changed, 335 insertions, 325 deletions
diff --git a/doc/administration/audit_events.md b/doc/administration/audit_events.md index b6089e84d3c..b380338baef 100644 --- a/doc/administration/audit_events.md +++ b/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  -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 diff --git a/doc/administration/auth/ldap/google_secure_ldap.md b/doc/administration/auth/ldap/google_secure_ldap.md index 1f8fca33811..90f0e681dd1 100644 --- a/doc/administration/auth/ldap/google_secure_ldap.md +++ b/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'.  diff --git a/doc/administration/auth/ldap/index.md b/doc/administration/auth/ldap/index.md index 6c21d3707af..4f1037f4f2d 100644 --- a/doc/administration/auth/ldap/index.md +++ b/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. diff --git a/doc/administration/auth/ldap/ldap-troubleshooting.md b/doc/administration/auth/ldap/ldap-troubleshooting.md index e823dc61023..3d3ac124ac4 100644 --- a/doc/administration/auth/ldap/ldap-troubleshooting.md +++ b/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 diff --git a/doc/administration/compliance.md b/doc/administration/compliance.md index 47e4b6c068c..237261f2567 100644 --- a/doc/administration/compliance.md +++ b/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+|| diff --git a/doc/administration/database_load_balancing.md b/doc/administration/database_load_balancing.md index 0f566fcc114..36ef905fd90 100644 --- a/doc/administration/database_load_balancing.md +++ b/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 diff --git a/doc/administration/geo/disaster_recovery/index.md b/doc/administration/geo/disaster_recovery/index.md index e9b566b7849..cc7a7045f0e 100644 --- a/doc/administration/geo/disaster_recovery/index.md +++ b/doc/administration/geo/disaster_recovery/index.md @@ -98,6 +98,10 @@ must disable the **primary** node. Note the following when promoting a secondary: +- If replication was paused on the secondary node, for example as a part of upgrading, + while you were running a version of GitLab lower than 13.4, you _must_ + [enable the node via the database](#while-promoting-the-secondary-i-got-an-error-activerecordrecordinvalid) + before proceeding. - A new **secondary** should not be added at this time. If you want to add a new **secondary**, do this after you have completed the entire process of promoting the **secondary** to the **primary**. @@ -427,3 +431,20 @@ instructions in the [Upgrading to GitLab 10.5](../replication/version_specific_updates.md#updating-to-gitlab-105) section to resolve the error. Otherwise, the secret is lost and you'll need to [reset two-factor authentication for all users](../../../security/two_factor_authentication.md#disabling-2fa-for-everyone). + +### While Promoting the secondary, I got an error `ActiveRecord::RecordInvalid` + +If you disabled a secondary node, either with the [replication pause task](../replication/index.md#pausing-and-resuming-replication) +(13.2) or via the UI (13.1 and earlier), you must first re-enable the +node before you can continue. This is fixed in 13.4. + +From `gitlab-psql`, execute the following, replacing `<your secondary url>` +with the URL for your secondary server starting with `http` or `https` and ending with a `/`. + +```shell +SECONDARY_URL="https://<secondary url>/" +DATABASE_NAME="gitlabhq_production" +sudo gitlab-psql -d "$DATABASE_NAME" -c "UPDATE geo_nodes SET enabled = true WHERE url = '$SECONDARY_URL';" +``` + +This should update 1 row. diff --git a/doc/administration/geo/replication/datatypes.md b/doc/administration/geo/replication/datatypes.md index b8d01e80371..e4330076599 100644 --- a/doc/administration/geo/replication/datatypes.md +++ b/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)** diff --git a/doc/administration/geo/replication/object_storage.md b/doc/administration/geo/replication/object_storage.md index 159e2524198..53736a91190 100644 --- a/doc/administration/geo/replication/object_storage.md +++ b/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: diff --git a/doc/administration/incoming_email.md b/doc/administration/incoming_email.md index 36156c4a580..9de9a38bae4 100644 --- a/doc/administration/incoming_email.md +++ b/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 diff --git a/doc/administration/index.md b/doc/administration/index.md index c46564506f5..63965e201a8 100644 --- a/doc/administration/index.md +++ b/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 diff --git a/doc/administration/instance_limits.md b/doc/administration/instance_limits.md index bf4e00a2d53..c3453337aaa 100644 --- a/doc/administration/instance_limits.md +++ b/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) diff --git a/doc/administration/job_artifacts.md b/doc/administration/job_artifacts.md index 66a7bcb90f6..2a79923b793 100644 --- a/doc/administration/job_artifacts.md +++ b/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 diff --git a/doc/administration/monitoring/gitlab_self_monitoring_project/index.md b/doc/administration/monitoring/gitlab_self_monitoring_project/index.md index e272cccb7ce..efe31997b25 100644 --- a/doc/administration/monitoring/gitlab_self_monitoring_project/index.md +++ b/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. diff --git a/doc/administration/object_storage.md b/doc/administration/object_storage.md index 024e71a89ae..b83665c51a5 100644 --- a/doc/administration/object_storage.md +++ b/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 diff --git a/doc/administration/pages/source.md b/doc/administration/pages/source.md index 486bc7a8777..998cab0dfa3 100644 --- a/doc/administration/pages/source.md +++ b/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 diff --git a/doc/administration/raketasks/ldap.md b/doc/administration/raketasks/ldap.md index 30bb9828aa0..6d04a786d3a 100644 --- a/doc/administration/raketasks/ldap.md +++ b/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** diff --git a/doc/administration/raketasks/uploads/migrate.md b/doc/administration/raketasks/uploads/migrate.md index 8427575ea4b..8d61beea597 100644 --- a/doc/administration/raketasks/uploads/migrate.md +++ b/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). diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md index 5fdf31339ff..6afdf31a481 100644 --- a/doc/administration/reference_architectures/10k_users.md +++ b/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. diff --git a/doc/administration/reference_architectures/1k_users.md b/doc/administration/reference_architectures/1k_users.md index d3cf5f49413..d376c1b7575 100644 --- a/doc/administration/reference_architectures/1k_users.md +++ b/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 diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md index 7ef8c688eed..0aef42ec849 100644 --- a/doc/administration/reference_architectures/25k_users.md +++ b/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. diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md index 55c2f05a3af..5583884e712 100644 --- a/doc/administration/reference_architectures/2k_users.md +++ b/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. diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md index e3827ade735..ddc477c156f 100644 --- a/doc/administration/reference_architectures/3k_users.md +++ b/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. diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md index 60cd82b9896..60521c05a6c 100644 --- a/doc/administration/reference_architectures/50k_users.md +++ b/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. diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md index 67803a8064c..319820d8268 100644 --- a/doc/administration/reference_architectures/5k_users.md +++ b/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. diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md index 4f7be2413dd..d15a576a302 100644 --- a/doc/administration/reference_architectures/index.md +++ b/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. diff --git a/doc/analytics/README.md b/doc/analytics/README.md index bfb15f6c4f3..c88f6b4c7cc 100644 --- a/doc/analytics/README.md +++ b/doc/analytics/README.md @@ -1,5 +1,5 @@ --- -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) diff --git a/doc/api/audit_events.md b/doc/api/audit_events.md index ce2a9afd53c..5f31919c52b 100644 --- a/doc/api/audit_events.md +++ b/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. diff --git a/doc/api/epic_links.md b/doc/api/epic_links.md index a2477123ce4..8a9abf8f08c 100644 --- a/doc/api/epic_links.md +++ b/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. diff --git a/doc/api/groups.md b/doc/api/groups.md index c1556fb8e79..ae3300e24fb 100644 --- a/doc/api/groups.md +++ b/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. diff --git a/doc/api/job_artifacts.md b/doc/api/job_artifacts.md index 5df7915ad5c..458877d6548 100644 --- a/doc/api/job_artifacts.md +++ b/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: diff --git a/doc/api/project_templates.md b/doc/api/project_templates.md index e08ff56925e..b502b60b513 100644 --- a/doc/api/project_templates.md +++ b/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 diff --git a/doc/api/projects.md b/doc/api/projects.md index d10b246517c..ad26457ad99 100644 --- a/doc/api/projects.md +++ b/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 diff --git a/doc/api/protected_branches.md b/doc/api/protected_branches.md index 8a3ff1b20e7..05d586738d0 100644 --- a/doc/api/protected_branches.md +++ b/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" diff --git a/doc/api/remote_mirrors.md b/doc/api/remote_mirrors.md index a8355fb9009..605284caf06 100644 --- a/doc/api/remote_mirrors.md +++ b/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. diff --git a/doc/api/users.md b/doc/api/users.md index c3fbd559b74..26d9a79a165 100644 --- a/doc/api/users.md +++ b/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 diff --git a/doc/api/visual_review_discussions.md b/doc/api/visual_review_discussions.md index c9863784038..7e741688949 100644 --- a/doc/api/visual_review_discussions.md +++ b/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 diff --git a/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md b/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md index ba801950c40..74c48f087b2 100644 --- a/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md +++ b/doc/ci/ci_cd_for_external_repos/bitbucket_integration.md @@ -19,7 +19,7 @@ To use GitLab CI/CD with a Bitbucket Cloud repository:  - 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) diff --git a/doc/ci/ci_cd_for_external_repos/github_integration.md b/doc/ci/ci_cd_for_external_repos/github_integration.md index dc1135742ea..661d935fc1d 100644 --- a/doc/ci/ci_cd_for_external_repos/github_integration.md +++ b/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 diff --git a/doc/ci/directed_acyclic_graph/index.md b/doc/ci/directed_acyclic_graph/index.md index ed1528bf6ca..19da0496f8a 100644 --- a/doc/ci/directed_acyclic_graph/index.md +++ b/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. diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md index 685c93b3be4..15dad1306fc 100644 --- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md +++ b/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**. diff --git a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md b/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md index d91d88c8e12..1f88e8f832f 100644 --- a/doc/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md +++ b/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**. diff --git a/doc/ci/metrics_reports.md b/doc/ci/metrics_reports.md index ea1994235fd..4f4471225a0 100644 --- a/doc/ci/metrics_reports.md +++ b/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: diff --git a/doc/ci/migration/jenkins.md b/doc/ci/migration/jenkins.md index 6857e736580..0dc0154d4a8 100644 --- a/doc/ci/migration/jenkins.md +++ b/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 diff --git a/doc/ci/pipelines/index.md b/doc/ci/pipelines/index.md index 97a58a1b0b8..5d9a533f6d5 100644 --- a/doc/ci/pipelines/index.md +++ b/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:  -[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 diff --git a/doc/ci/pipelines/job_artifacts.md b/doc/ci/pipelines/job_artifacts.md index de881ff160e..750a76bfaa0 100644 --- a/doc/ci/pipelines/job_artifacts.md +++ b/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) diff --git a/doc/ci/pipelines/settings.md b/doc/ci/pipelines/settings.md index bd3587793c1..849eb66d07f 100644 --- a/doc/ci/pipelines/settings.md +++ b/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 diff --git a/doc/ci/quick_start/README.md b/doc/ci/quick_start/README.md index 2a33f09c725..bf299c97862 100644 --- a/doc/ci/quick_start/README.md +++ b/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**. diff --git a/doc/ci/runners/README.md b/doc/ci/runners/README.md index 6b2556d00ae..f1476f8022f 100644 --- a/doc/ci/runners/README.md +++ b/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: diff --git a/doc/ci/unit_test_reports.md b/doc/ci/unit_test_reports.md index 9d803c300f2..294b71efd38 100644 --- a/doc/ci/unit_test_reports.md +++ b/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. diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md index fd698fb65b1..438ef8e59c4 100644 --- a/doc/ci/variables/README.md +++ b/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, diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 59a9ed217aa..246f5d2992a 100644 --- a/doc/ci/yaml/README.md +++ b/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` diff --git a/doc/development/approval_rules.md b/doc/development/approval_rules.md index 65df82721de..f295c20a36f 100644 --- a/doc/development/approval_rules.md +++ b/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` diff --git a/doc/development/cicd/index.md b/doc/development/cicd/index.md index 28cf67105f6..585133ae9a2 100644 --- a/doc/development/cicd/index.md +++ b/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. diff --git a/doc/development/code_review.md b/doc/development/code_review.md index 9a18af34866..070e57b5dec 100644 --- a/doc/development/code_review.md +++ b/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. diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md index 33004037fae..bde4a2844f2 100644 --- a/doc/development/contributing/issue_workflow.md +++ b/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. diff --git a/doc/development/documentation/workflow.md b/doc/development/documentation/workflow.md index c3e15cb1b2b..488c71a6328 100644 --- a/doc/development/documentation/workflow.md +++ b/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). diff --git a/doc/development/elasticsearch.md b/doc/development/elasticsearch.md index 614b2579ec3..da45cadc191 100644 --- a/doc/development/elasticsearch.md +++ b/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 diff --git a/doc/development/integrations/secure_partner_integration.md b/doc/development/integrations/secure_partner_integration.md index 19a497641f9..830cb84e257 100644 --- a/doc/development/integrations/secure_partner_integration.md +++ b/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: diff --git a/doc/development/repository_mirroring.md b/doc/development/repository_mirroring.md index 1d4dbe88399..fe6db987471 100644 --- a/doc/development/repository_mirroring.md +++ b/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). diff --git a/doc/getting-started/subscription.md b/doc/getting-started/subscription.md index 65999183d4a..8bcd11c20c8 100644 --- a/doc/getting-started/subscription.md +++ b/doc/getting-started/subscription.md @@ -1,3 +1,3 @@ --- redirect_to: '../subscriptions/index.md' ----
\ No newline at end of file +--- diff --git a/doc/gitlab-basics/create-project.md b/doc/gitlab-basics/create-project.md index 929062102bb..f411ac769c0 100644 --- a/doc/gitlab-basics/create-project.md +++ b/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 diff --git a/doc/install/azure/index.md b/doc/install/azure/index.md index 548c7d8c92e..00c868c6c41 100644 --- a/doc/install/azure/index.md +++ b/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/) diff --git a/doc/integration/kerberos.md b/doc/integration/kerberos.md index 09bc795f7ef..1b14b5a986f 100644 --- a/doc/integration/kerberos.md +++ b/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 diff --git a/doc/operations/incident_management/incidents.md b/doc/operations/incident_management/incidents.md index f48b6a12f49..528d29f9343 100644 --- a/doc/operations/incident_management/incidents.md +++ b/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 diff --git a/doc/operations/index.md b/doc/operations/index.md index bcc3f89f47f..7ab34502277 100644 --- a/doc/operations/index.md +++ b/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. diff --git a/doc/operations/metrics/alerts.md b/doc/operations/metrics/alerts.md index 90cc70c8e53..a575d28bdd5 100644 --- a/doc/operations/metrics/alerts.md +++ b/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 diff --git a/doc/operations/metrics/index.md b/doc/operations/metrics/index.md index 92c4a4986bc..0ee1927a512 100644 --- a/doc/operations/metrics/index.md +++ b/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 diff --git a/doc/push_rules/push_rules.md b/doc/push_rules/push_rules.md index 6a3939b0de8..1643c96d229 100644 --- a/doc/push_rules/push_rules.md +++ b/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 diff --git a/doc/topics/application_development_platform/index.md b/doc/topics/application_development_platform/index.md index 06cae63cbe3..85741c4b631 100644 --- a/doc/topics/application_development_platform/index.md +++ b/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 diff --git a/doc/topics/autodevops/customize.md b/doc/topics/autodevops/customize.md index 5359652a5f4..3192c092f29 100644 --- a/doc/topics/autodevops/customize.md +++ b/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: diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index e8a344a41d7..a39f93a26e1 100644 --- a/doc/topics/autodevops/index.md +++ b/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: diff --git a/doc/topics/autodevops/quick_start_guide.md b/doc/topics/autodevops/quick_start_guide.md index 6b9b461e76e..288075a3ddf 100644 --- a/doc/topics/autodevops/quick_start_guide.md +++ b/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) diff --git a/doc/user/admin_area/analytics/dev_ops_report.md b/doc/user/admin_area/analytics/dev_ops_report.md index 8ddd093893c..f04bd69b76b 100644 --- a/doc/user/admin_area/analytics/dev_ops_report.md +++ b/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. diff --git a/doc/user/admin_area/index.md b/doc/user/admin_area/index.md index 8aa50bb0496..90869997ec7 100644 --- a/doc/user/admin_area/index.md +++ b/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. | diff --git a/doc/user/admin_area/settings/account_and_limit_settings.md b/doc/user/admin_area/settings/account_and_limit_settings.md index 4651a548ff9..5cdbc8ebd4f 100644 --- a/doc/user/admin_area/settings/account_and_limit_settings.md +++ b/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. diff --git a/doc/user/admin_area/settings/index.md b/doc/user/admin_area/settings/index.md index db6dbb7f38b..ba9bccbf3e7 100644 --- a/doc/user/admin_area/settings/index.md +++ b/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 diff --git a/doc/user/admin_area/settings/visibility_and_access_controls.md b/doc/user/admin_area/settings/visibility_and_access_controls.md index e5c7947399d..95a87378e18 100644 --- a/doc/user/admin_area/settings/visibility_and_access_controls.md +++ b/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 diff --git a/doc/user/analytics/value_stream_analytics.md b/doc/user/analytics/value_stream_analytics.md index 5a0daca6c26..7c83f5a0e0c 100644 --- a/doc/user/analytics/value_stream_analytics.md +++ b/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: diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md index 6b7086ddc71..84311b86afa 100644 --- a/doc/user/application_security/container_scanning/index.md +++ b/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. diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md index b8c17f1cf2f..41e51f5d2fd 100644 --- a/doc/user/application_security/dast/index.md +++ b/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. diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md index 1350e2c6c25..62c64e74328 100644 --- a/doc/user/application_security/dependency_scanning/index.md +++ b/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. diff --git a/doc/user/application_security/index.md b/doc/user/application_security/index.md index c3477fdcbb6..332ab81cbcc 100644 --- a/doc/user/application_security/index.md +++ b/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). diff --git a/doc/user/application_security/sast/index.md b/doc/user/application_security/sast/index.md index 2c0afa76287..10ffaf6ad7f 100644 --- a/doc/user/application_security/sast/index.md +++ b/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 | |------------------------------------------|---------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| diff --git a/doc/user/application_security/secret_detection/index.md b/doc/user/application_security/secret_detection/index.md index 7daf2f3308b..1089bbfc8c8 100644 --- a/doc/user/application_security/secret_detection/index.md +++ b/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. diff --git a/doc/user/compliance/license_compliance/index.md b/doc/user/compliance/license_compliance/index.md index 3bf6f310751..af76ff7061e 100644 --- a/doc/user/compliance/license_compliance/index.md +++ b/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) diff --git a/doc/user/discussions/index.md b/doc/user/discussions/index.md index f39d0d6c217..d3576ea33fe 100644 --- a/doc/user/discussions/index.md +++ b/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. diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md index 2e16e9fd73e..68f877cd3ac 100644 --- a/doc/user/gitlab_com/index.md +++ b/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). diff --git a/doc/user/group/clusters/index.md b/doc/user/group/clusters/index.md index e61b24f84f6..7326135006b 100644 --- a/doc/user/group/clusters/index.md +++ b/doc/user/group/clusters/index.md @@ -46,7 +46,7 @@ You can associate more than one Kubernetes cluster to your group, and maintain d for different environments, such as development, staging, and production. When adding another cluster, -[set an environment scope](#environment-scopes-premium) to help +[set an environment scope](#environment-scopes) to help differentiate the new cluster from your other clusters. ## GitLab-managed clusters diff --git a/doc/user/group/epics/index.md b/doc/user/group/epics/index.md index 04b57d13828..e8bcb7219fc 100644 --- a/doc/user/group/epics/index.md +++ b/doc/user/group/epics/index.md @@ -48,14 +48,14 @@ To learn what you can do with an epic, see [Manage epics](manage_epics.md). Poss - [Search for an epic from epics list page](manage_epics.md#search-for-an-epic-from-epics-list-page) - [Make an epic confidential](manage_epics.md#make-an-epic-confidential) - [Manage issues assigned to an epic](manage_epics.md#manage-issues-assigned-to-an-epic) -- [Manage multi-level child epics **(ULTIMATE)**](manage_epics.md#manage-multi-level-child-epics-ultimate) +- [Manage multi-level child epics **(ULTIMATE)**](manage_epics.md#manage-multi-level-child-epics) ## Relationships between epics and issues The possible relationships between epics and issues are: - An epic is the parent of one or more issues. -- An epic is the parent of one or more child epics. For details see [Multi-level child epics](#multi-level-child-epics-ultimate). **(ULTIMATE)** +- An epic is the parent of one or more child epics. For details see [Multi-level child epics](#multi-level-child-epics). **(ULTIMATE)** ```mermaid graph TD @@ -73,7 +73,7 @@ to add an issue to an epic, reorder issues, move issues between epics, or promot > - The health status of a closed issue [will be hidden](https://gitlab.com/gitlab-org/gitlab/-/issues/220867) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.3 or later. You can report on and quickly respond to the health of individual issues and epics by setting a -red, amber, or green [health status on an issue](../../project/issues/index.md#health-status-ultimate), +red, amber, or green [health status on an issue](../../project/issues/index.md#health-status), which will appear on your Epic tree. ### Disable Issue health status in Epic tree @@ -92,7 +92,7 @@ When you add an epic that's already linked to a parent epic, the link to its cur An epic can have multiple child epics up to the maximum depth of five. -See [Manage multi-level child epics](manage_epics.md#manage-multi-level-child-epics-ultimate) for +See [Manage multi-level child epics](manage_epics.md#manage-multi-level-child-epics) for steps to create, move, reorder, or delete child epics. ## Start date and due date @@ -145,7 +145,7 @@ then the parent epic's start date will reflect the change and this will propagat > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/7327) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.10. -If your epic contains one or more [child epics](#multi-level-child-epics-ultimate) which +If your epic contains one or more [child epics](#multi-level-child-epics) which have a [start or due date](#start-date-and-due-date), a [roadmap](../roadmap/index.md) view of the child epics is listed under the parent epic. diff --git a/doc/user/group/index.md b/doc/user/group/index.md index 16b561f7ec1..29a2f284014 100644 --- a/doc/user/group/index.md +++ b/doc/user/group/index.md @@ -227,7 +227,7 @@ To change this setting for a specific group: To change this setting globally, see [Default branch protection](../admin_area/settings/visibility_and_access_controls.md#default-branch-protection). NOTE: **Note:** -In [GitLab Premium or higher](https://about.gitlab.com/pricing/), GitLab administrators can choose to [disable group owners from updating the default branch protection](../admin_area/settings/visibility_and_access_controls.md#disable-group-owners-from-updating-default-branch-protection-premium-only). +In [GitLab Premium or higher](https://about.gitlab.com/pricing/), GitLab administrators can choose to [disable group owners from updating the default branch protection](../admin_area/settings/visibility_and_access_controls.md#disable-group-owners-from-updating-default-branch-protection). ## Add projects to a group @@ -340,7 +340,7 @@ Group syncing allows LDAP groups to be mapped to GitLab groups. This provides mo Group links can be created using either a CN or a filter. These group links are created on the **Group Settings -> LDAP Synchronization** page. After configuring the link, it may take over an hour for the users to sync with the GitLab group. -For more information on the administration of LDAP and group sync, refer to the [main LDAP documentation](../../administration/auth/ldap/index.md#group-sync-starter-only). +For more information on the administration of LDAP and group sync, refer to the [main LDAP documentation](../../administration/auth/ldap/index.md#group-sync). NOTE: **Note:** If an LDAP user is a group member when LDAP Synchronization is added, and they are not part of the LDAP group, they will be removed from the group. @@ -363,7 +363,7 @@ To create group links via filter: 1. Select the **LDAP Server** for the link. 1. Select `LDAP user filter` as the **Sync method**. -1. Input your filter in the **LDAP User filter** box. Follow the [documentation on user filters](../../administration/auth/ldap/index.md#set-up-ldap-user-filter-core-only). +1. Input your filter in the **LDAP User filter** box. Follow the [documentation on user filters](../../administration/auth/ldap/index.md#set-up-ldap-user-filter). 1. In the **LDAP Access** section, select the [permission level](../permissions.md) for users synced in this group. 1. Click the `Add Synchronization` button to save this group link. @@ -480,7 +480,7 @@ To remove a group and its contents: This action either: - Removes the group, and also queues a background job to delete all projects in that group. -- Since [GitLab 12.8](https://gitlab.com/gitlab-org/gitlab/-/issues/33257), on [Premium or Silver](https://about.gitlab.com/pricing/premium/) 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](../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/premium/) 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](../admin_area/settings/visibility_and_access_controls.md#default-deletion-delay). ### Restore a group **(PREMIUM)** @@ -660,7 +660,7 @@ Optionally, on [Premium or Silver](https://about.gitlab.com/pricing/) or higher you can configure the projects within a group to be deleted after a delayed interval. During this interval period, the projects will be in a read-only state and can be restored, if required. -The interval period defaults to 7 days, and can be modified by an admin in the [instance settings](../admin_area/settings/visibility_and_access_controls.md#default-deletion-delay-premium-only). +The interval period defaults to 7 days, and can be modified by an admin in the [instance settings](../admin_area/settings/visibility_and_access_controls.md#default-deletion-delay). To enable delayed deletion of projects: @@ -728,7 +728,7 @@ When set, new subgroups have push rules set for them based on either: ### Maximum artifacts size **(CORE ONLY)** For information about setting a maximum artifact size for a group, see -[Maximum artifacts size](../admin_area/settings/continuous_integration.md#maximum-artifacts-size-core-only). +[Maximum artifacts size](../admin_area/settings/continuous_integration.md#maximum-artifacts-size). ## User contribution analysis **(STARTER)** diff --git a/doc/user/group/iterations/index.md b/doc/user/group/iterations/index.md index 43041456060..20cbc043d83 100644 --- a/doc/user/group/iterations/index.md +++ b/doc/user/group/iterations/index.md @@ -13,7 +13,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w > - It's enabled on GitLab.com. > - It's able to be enabled or disabled per-group. > - It's recommended for production use. -> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#disable-iterations-core-only). **(CORE ONLY)** +> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#disable-iterations). **(CORE ONLY)** Iterations are a way to track issues over a period of time. This allows teams to track velocity and volatility metrics. Iterations can be used with [milestones](../../project/milestones/index.md) @@ -62,7 +62,7 @@ To edit an iteration, click the three-dot menu (**{ellipsis_v}**) > **Edit itera > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216158) in [GitLab Starter](https://about.gitlab.com/pricing/) 13.2. To learn how to add an issue to an iteration, see the steps in -[Managing issues](../../project/issues/managing_issues.md#add-an-issue-to-an-iteration-starter). +[Managing issues](../../project/issues/managing_issues.md#add-an-issue-to-an-iteration). ## Disable Iterations **(CORE ONLY)** diff --git a/doc/user/group/saml_sso/group_managed_accounts.md b/doc/user/group/saml_sso/group_managed_accounts.md index 218570cf872..7497d036d31 100644 --- a/doc/user/group/saml_sso/group_managed_accounts.md +++ b/doc/user/group/saml_sso/group_managed_accounts.md @@ -105,7 +105,7 @@ Since personal access tokens are the only token needed for programmatic access t ### Setting a limit -Only a GitLab administrator or an owner of a group-managed account can set a limit. When this field is left empty, the [instance-level restriction](../../admin_area/settings/account_and_limit_settings.md#limiting-lifetime-of-personal-access-tokens-ultimate-only) on the lifetime of personal access tokens apply. +Only a GitLab administrator or an owner of a group-managed account can set a limit. When this field is left empty, the [instance-level restriction](../../admin_area/settings/account_and_limit_settings.md#limiting-lifetime-of-personal-access-tokens) on the lifetime of personal access tokens apply. To set a limit on how long personal access tokens are valid for users in a group managed account: diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md index bb7420e24e9..8be8474fcd0 100644 --- a/doc/user/group/saml_sso/index.md +++ b/doc/user/group/saml_sso/index.md @@ -274,10 +274,10 @@ Group SAML on a self-managed instance is limited when compared to the recommende [instance-wide SAML](../../../integration/saml.md). The recommended solution allows you to take advantage of: - [LDAP compatibility](../../../administration/auth/ldap/index.md). -- [LDAP Group Sync](../index.md#manage-group-memberships-via-ldap-starter-only). -- [Required groups](../../../integration/saml.md#required-groups-starter-only). -- [Admin groups](../../../integration/saml.md#admin-groups-starter-only). -- [Auditor groups](../../../integration/saml.md#auditor-groups-starter-only). +- [LDAP Group Sync](../index.md#manage-group-memberships-via-ldap). +- [Required groups](../../../integration/saml.md#required-groups). +- [Admin groups](../../../integration/saml.md#admin-groups). +- [Auditor groups](../../../integration/saml.md#auditor-groups). ### Omnibus installations diff --git a/doc/user/permissions.md b/doc/user/permissions.md index c8ebbba27f9..cddb2ab3188 100644 --- a/doc/user/permissions.md +++ b/doc/user/permissions.md @@ -55,7 +55,7 @@ The following table depicts the various user permission levels in a project. | View [Design Management](project/issues/design_management.md) pages | ✓ | ✓ | ✓ | ✓ | ✓ | | View project code | ✓ (*1*) | ✓ | ✓ | ✓ | ✓ | | Pull project code | ✓ (*1*) | ✓ | ✓ | ✓ | ✓ | -| View GitLab Pages protected by [access control](project/pages/introduction.md#gitlab-pages-access-control-core) | ✓ | ✓ | ✓ | ✓ | ✓ | +| View GitLab Pages protected by [access control](project/pages/introduction.md#gitlab-pages-access-control) | ✓ | ✓ | ✓ | ✓ | ✓ | | View wiki pages | ✓ | ✓ | ✓ | ✓ | ✓ | | See a list of jobs | ✓ (*3*) | ✓ | ✓ | ✓ | ✓ | | See a job log | ✓ (*3*) | ✓ | ✓ | ✓ | ✓ | @@ -365,7 +365,7 @@ are unable to browse the project's repository, for example). TIP: **Tip:** To prevent a guest user from creating projects, as an admin, you can edit the -user's profile to mark the user as [external](#external-users-core-only). +user's profile to mark the user as [external](#external-users). Beware though that even if a user is external, if they already have Reporter or higher permissions in any project or group, they are **not** counted as a free guest user. @@ -472,9 +472,9 @@ for details about the pipelines security model. ## LDAP users permissions Since GitLab 8.15, LDAP user permissions can now be manually overridden by an admin user. -Read through the documentation on [LDAP users permissions](group/index.md#manage-group-memberships-via-ldap-starter-only) to learn more. +Read through the documentation on [LDAP users permissions](group/index.md#manage-group-memberships-via-ldap) to learn more. ## Project aliases Project aliases can only be read, created and deleted by a GitLab administrator. -Read through the documentation on [Project aliases](../user/project/index.md#project-aliases-premium-only) to learn more. +Read through the documentation on [Project aliases](../user/project/index.md#project-aliases) to learn more. diff --git a/doc/user/profile/personal_access_tokens.md b/doc/user/profile/personal_access_tokens.md index 776dc4542ee..737fa85fec6 100644 --- a/doc/user/profile/personal_access_tokens.md +++ b/doc/user/profile/personal_access_tokens.md @@ -20,9 +20,9 @@ Personal access tokens expire on the date you define, at midnight UTC. - GitLab runs a check at 01:00 AM UTC every day to identify personal access tokens that expire in under seven days. The owners of these tokens are notified by email. - GitLab runs a check at 02:00 AM UTC every day to identify personal access tokens that expired on the current date. The owners of these tokens are notified by email. -To turn on the notification for expired personal access tokens in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-notification-for-expired-personal-access-token-core-only). **(CORE ONLY)** -- In GitLab Ultimate, administrators may [limit the lifetime of personal access tokens](../admin_area/settings/account_and_limit_settings.md#limiting-lifetime-of-personal-access-tokens-ultimate-only). -- In GitLab Ultimate, administrators may [toggle enforcement of personal access token expiry](../admin_area/settings/account_and_limit_settings.md#optional-enforcement-of-personal-access-token-expiry-ultimate-only). +To turn on the notification for expired personal access tokens in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-notification-for-expired-personal-access-token). **(CORE ONLY)** +- In GitLab Ultimate, administrators may [limit the lifetime of personal access tokens](../admin_area/settings/account_and_limit_settings.md#limiting-lifetime-of-personal-access-tokens). +- In GitLab Ultimate, administrators may [toggle enforcement of personal access token expiry](../admin_area/settings/account_and_limit_settings.md#optional-enforcement-of-personal-access-token-expiry). For examples of how you can use a personal access token to authenticate with the API, see the following section from our [API Docs](../../api/README.md#personalproject-access-tokens). diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md index 98078854050..efb323baf4f 100644 --- a/doc/user/project/clusters/index.md +++ b/doc/user/project/clusters/index.md @@ -22,8 +22,8 @@ Using the GitLab project Kubernetes integration, you can: - Detect and [monitor Kubernetes](#monitoring-your-kubernetes-cluster). - Use it with [Auto DevOps](#auto-devops). - Use [Web terminals](#web-terminals). -- Use [Deploy Boards](#deploy-boards-premium). **(PREMIUM)** -- Use [Canary Deployments](#canary-deployments-premium). **(PREMIUM)** +- Use [Deploy Boards](#deploy-boards). **(PREMIUM)** +- Use [Canary Deployments](#canary-deployments). **(PREMIUM)** - View [Logs](#viewing-pod-logs). - Run serverless workloads on [Kubernetes with Knative](serverless/index.md). diff --git a/doc/user/project/code_owners.md b/doc/user/project/code_owners.md index dbe3f3dc891..8c7de16a7d6 100644 --- a/doc/user/project/code_owners.md +++ b/doc/user/project/code_owners.md @@ -74,7 +74,7 @@ Once you've added Code Owners to a project, you can configure it to be used for merge request approvals: - As [merge request eligible approvers](merge_requests/merge_request_approvals.md#code-owners-as-eligible-approvers). -- As required approvers for [protected branches](protected_branches.md#protected-branches-approval-by-code-owners-premium). **(PREMIUM)** +- As required approvers for [protected branches](protected_branches.md#protected-branches-approval-by-code-owners). **(PREMIUM)** NOTE: **Note:** Developer or higher [permissions](../permissions.md) are required in order to @@ -88,11 +88,11 @@ While the `CODEOWNERS` file can be used in addition to Merge Request [Approval R it can also be used as the sole driver of merge request approvals (without using [Approval Rules](merge_requests/merge_request_approvals.md#approval-rules)). To do so, create the file in one of the three locations specified above and -set the code owners as required approvers for [protected branches](protected_branches.md#protected-branches-approval-by-code-owners-premium). +set the code owners as required approvers for [protected branches](protected_branches.md#protected-branches-approval-by-code-owners). Use [the syntax of Code Owners files](code_owners.md#the-syntax-of-code-owners-files) to specify the actual owners and granular permissions. -Using Code Owners in conjunction with [Protected Branches](protected_branches.md#protected-branches-approval-by-code-owners-premium) +Using Code Owners in conjunction with [Protected Branches](protected_branches.md#protected-branches-approval-by-code-owners) will prevent any user who is not specified in the `CODEOWNERS` file from pushing changes for the specified files/paths, even if their role is included in the **Allowed to push** column. This allows for a more inclusive push strategy, as @@ -150,7 +150,7 @@ escaped using `\#` to address files for which the name starts with a > - It's enabled on GitLab.com. > - It can be enabled or disabled per-project. > - It's recommended for production use. -> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-code-owner-sections-core-only). **(CORE ONLY)** +> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-code-owner-sections). **(CORE ONLY)** Code Owner rules can be grouped into named sections. This allows for better organization of broader categories of Code Owner rules to be applied. diff --git a/doc/user/project/file_lock.md b/doc/user/project/file_lock.md index 24019bedc3f..ab41cef5870 100644 --- a/doc/user/project/file_lock.md +++ b/doc/user/project/file_lock.md @@ -28,7 +28,7 @@ GitLab supports two different modes of file locking: - [Exclusive file locks](#exclusive-file-locks) for binary files: done **through the command line** with Git LFS and `.gitattributes`, it prevents locked files from being modified on any branch. **(CORE)** -- [Default branch locks](#default-branch-file-and-directory-locks-premium): done +- [Default branch locks](#default-branch-file-and-directory-locks): done **through the GitLab UI**, it prevents locked files and directories being modified on the default branch. **(PREMIUM)** diff --git a/doc/user/project/index.md b/doc/user/project/index.md index ef2de127d56..a49c5fe054a 100644 --- a/doc/user/project/index.md +++ b/doc/user/project/index.md @@ -193,7 +193,7 @@ To delete a project, first navigate to the home page for that project. ### Delayed deletion **(PREMIUM)** By default, clicking to delete a project is followed by a seven day delay. Admins can restore the project during this period of time. -This delay [may be changed by an admin](../admin_area/settings/visibility_and_access_controls.md#default-deletion-delay-premium-only). +This delay [may be changed by an admin](../admin_area/settings/visibility_and_access_controls.md#default-deletion-delay). Admins can view all projects pending deletion. If you're an administrator, go to the top navigation bar, click **Projects > Your projects**, and then select the **Deleted projects** tab. From this tab an admin can restore any project. diff --git a/doc/user/project/issue_board.md b/doc/user/project/issue_board.md index 7be58ce4ecb..963c3bfee25 100644 --- a/doc/user/project/issue_board.md +++ b/doc/user/project/issue_board.md @@ -36,7 +36,7 @@ the Issue Board feature (introduced in GitLab 8.11 - August 2016). - Create multiple issue boards per project. - Create multiple issue boards per group. **(PREMIUM)** -- Add lists for [assignees](#assignee-lists-premium) and [milestones](#milestone-lists-premium). **(PREMIUM)** +- Add lists for [assignees](#assignee-lists) and [milestones](#milestone-lists). **(PREMIUM)** Check all the [GitLab Enterprise features for issue boards](#gitlab-enterprise-features-for-issue-boards). @@ -155,8 +155,8 @@ that belong to it. Types of lists include: Always appears as the leftmost list. - **Closed** (default): all closed issues. Always appears as the rightmost list. - **Label list**: all open issues for a label. -- [**Assignee list**](#assignee-lists-premium): all open issues assigned to a user. -- [**Milestone list**](#milestone-lists-premium): all open issues for a milestone. +- [**Assignee list**](#assignee-lists): all open issues assigned to a user. +- [**Milestone list**](#milestone-lists): all open issues for a milestone. A **Card** is a box on a list, and it represents an issue. You can drag cards from one list to another to change their label, assignee, or milestone. The information you can see on a @@ -265,7 +265,7 @@ is hidden, allowing you to focus on issues in the board. The top of each list indicates the sum of issue weights for the issues that belong to that list. This is useful when using boards for capacity allocation, -especially in combination with [assignee lists](#assignee-lists-premium). +especially in combination with [assignee lists](#assignee-lists).  diff --git a/doc/user/project/issues/design_management.md b/doc/user/project/issues/design_management.md index 94136ae171d..f07a5de8141 100644 --- a/doc/user/project/issues/design_management.md +++ b/doc/user/project/issues/design_management.md @@ -231,7 +231,7 @@ available in the **Resolved Comment** area at the bottom of the right sidebar. > - 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-design-references-core-only). **(CORE ONLY)** +> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-design-references). **(CORE ONLY)** We support referring to designs in [Markdown](../../markdown.md), which is available throughout the application, including in merge request and issue descriptions, in discussions and comments, and in wiki pages. diff --git a/doc/user/project/issues/index.md b/doc/user/project/issues/index.md index 17d9cdb1e2a..02977375d7e 100644 --- a/doc/user/project/issues/index.md +++ b/doc/user/project/issues/index.md @@ -93,7 +93,7 @@ must be set. While you can view and manage the full details of an issue on the [issue page](#issue-page), you can also work with multiple issues at a time using the [Issues List](#issues-list), -[Issue Boards](#issue-boards), Issue references, and [Epics](#epics-premium)**(PREMIUM)**. +[Issue Boards](#issue-boards), Issue references, and [Epics](#epics)**(PREMIUM)**. Key actions for Issues include: @@ -199,7 +199,7 @@ After an issue is closed, its health status can't be edited and the "Edit" butto until the issue is reopened. You can then see issue statuses on the -[Epic tree](../../group/epics/index.md#issue-health-status-in-epic-tree-ultimate). +[Epic tree](../../group/epics/index.md#issue-health-status-in-epic-tree). #### Disable issue health status diff --git a/doc/user/project/issues/issue_data_and_actions.md b/doc/user/project/issues/issue_data_and_actions.md index 77c50f9178c..818bf375169 100644 --- a/doc/user/project/issues/issue_data_and_actions.md +++ b/doc/user/project/issues/issue_data_and_actions.md @@ -21,13 +21,13 @@ You can find all the information for that issue on one screen. - **1.** [New Issue, close issue (reopen issue, report issue)](#new-issue-close-issue-reopen-issue-report-issue) - **2.** [To Do](#to-do) - **3.** [Assignee](#assignee) - - **3.1.** [Multiple Assignees **(STARTER)**](#multiple-assignees-starter) -- **4.** [Epic **(PREMIUM)**](#epic-premium) + - **3.1.** [Multiple Assignees **(STARTER)**](#multiple-assignees) +- **4.** [Epic **(PREMIUM)**](#epic) - **5.** [Milestone](#milestone) - **6.** [Time tracking](#time-tracking) - **7.** [Due date](#due-date) - **8.** [Labels](#labels) -- **9.** [Weight **(STARTER)**](#weight-starter) +- **9.** [Weight **(STARTER)**](#weight) - **10.** [Confidentiality](#confidentiality) - **11.** [Lock issue](#lock-issue) - **12.** [Participants](#participants) @@ -36,7 +36,7 @@ You can find all the information for that issue on one screen. - **15.** [Edit](#edit) - **16.** [Description](#description) - **17.** [Mentions](#mentions) -- **18.** [Related Issues **(STARTER)**](#related-issues-starter) +- **18.** [Related Issues **(STARTER)**](#related-issues) - **19.** [Related Merge Requests](#related-merge-requests) - **20.** [Award emoji](#award-emoji) - **21.** [Show all activity](#show-all-activity) @@ -88,7 +88,7 @@ An issue can be assigned to: - Yourself. - Another person. -- [Many people](#multiple-assignees-starter). **(STARTER)** +- [Many people](#multiple-assignees). **(STARTER)** The assignee(s) can be changed as often as needed. The idea is that the assignees are responsible for that issue until it's reassigned to someone else to take it from there. diff --git a/doc/user/project/merge_requests/browser_performance_testing.md b/doc/user/project/merge_requests/browser_performance_testing.md index 6b16d907fb2..040ca4b439b 100644 --- a/doc/user/project/merge_requests/browser_performance_testing.md +++ b/doc/user/project/merge_requests/browser_performance_testing.md @@ -37,7 +37,7 @@ Consider the following workflow: ## How browser performance testing works First, define a job in your `.gitlab-ci.yml` file that generates the -[Browser Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsperformance-premium). +[Browser Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsperformance). GitLab then checks this report, compares key performance metrics for each page between the source and target branches, and shows the information in the merge request. @@ -85,7 +85,7 @@ The example uses a CI/CD template that is included in all GitLab installations s or older, you must [add the configuration manually](#gitlab-versions-123-and-older) The template uses the [GitLab plugin for sitespeed.io](https://gitlab.com/gitlab-org/gl-performance), -and it saves the full HTML sitespeed.io report as a [Browser Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsperformance-premium) +and it saves the full HTML sitespeed.io report as a [Browser Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsperformance) that you can later download and analyze. This implementation always takes the latest Browser Performance artifact available. If [GitLab Pages](../pages/index.md) is enabled, you can view the report directly in your browser. diff --git a/doc/user/project/merge_requests/code_quality.md b/doc/user/project/merge_requests/code_quality.md index 9fc824e2f44..112f4a082ff 100644 --- a/doc/user/project/merge_requests/code_quality.md +++ b/doc/user/project/merge_requests/code_quality.md @@ -23,7 +23,7 @@ Code Quality: Quality](https://gitlab.com/gitlab-org/ci-cd/codequality) project using [default Code Climate configurations](https://gitlab.com/gitlab-org/ci-cd/codequality/-/tree/master/codeclimate_defaults). - Can make use of a [template](#example-configuration). - Is available with [Auto - DevOps](../../../topics/autodevops/stages.md#auto-code-quality-starter). + DevOps](../../../topics/autodevops/stages.md#auto-code-quality). - Can be extended through [Analysis Plugins](https://docs.codeclimate.com/docs/list-of-engines) or a [custom tool](#implementing-a-custom-tool). ## Code Quality Widget diff --git a/doc/user/project/merge_requests/getting_started.md b/doc/user/project/merge_requests/getting_started.md index c7cabf3c73b..a0be32e0708 100644 --- a/doc/user/project/merge_requests/getting_started.md +++ b/doc/user/project/merge_requests/getting_started.md @@ -53,7 +53,7 @@ When you start a new merge request, you can immediately include the following options, or add them later by clicking the **Edit** button on the merge request's page at the top-right side: -- [Assign](#assignee) the merge request to a colleague for review. With GitLab Starter and higher tiers, you can [assign it to more than one person at a time](#multiple-assignees-starter). +- [Assign](#assignee) the merge request to a colleague for review. With GitLab Starter and higher tiers, you can [assign it to more than one person at a time](#multiple-assignees). - Set a [milestone](../milestones/index.md) to track time-sensitive changes. - Add [labels](../labels.md) to help contextualize and filter your merge requests over time. - Require [approval](merge_request_approvals.md) from your team. **(STARTER)** diff --git a/doc/user/project/merge_requests/load_performance_testing.md b/doc/user/project/merge_requests/load_performance_testing.md index ef42508234e..aadd2d965ef 100644 --- a/doc/user/project/merge_requests/load_performance_testing.md +++ b/doc/user/project/merge_requests/load_performance_testing.md @@ -28,7 +28,7 @@ GET calls to a popular API endpoint in your application to see how it performs. ## How Load Performance Testing works First, define a job in your `.gitlab-ci.yml` file that generates the -[Load Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsload_performance-premium). +[Load Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsload_performance). GitLab checks this report, compares key load performance metrics between the source and target branches, and then shows the information in a merge request widget: @@ -140,7 +140,7 @@ For example, you can override the duration of the test with a CLI option: GitLab only displays the key performance metrics in the MR widget if k6's results are saved via [summary export](https://k6.io/docs/results-visualization/json#summary-export) -as a [Load Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsload_performance-premium). +as a [Load Performance report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportsload_performance). The latest Load Performance artifact available is always used, using the summary values from the test. diff --git a/doc/user/project/merge_requests/merge_request_approvals.md b/doc/user/project/merge_requests/merge_request_approvals.md index cbfa87651f2..34c1e146da0 100644 --- a/doc/user/project/merge_requests/merge_request_approvals.md +++ b/doc/user/project/merge_requests/merge_request_approvals.md @@ -36,7 +36,7 @@ Required approvals enable multiple use cases: database, and so on, for all proposed code changes. - Designating [Code Owners as eligible approvers](#code-owners-as-eligible-approvers), determined by the files changed in a merge request. -- [Requiring approval from a security team](#security-approvals-in-merge-requests-ultimate) +- [Requiring approval from a security team](#security-approvals-in-merge-requests) before merging code that could introduce a vulnerability.**(ULTIMATE)** ### Approval Rules @@ -52,7 +52,7 @@ minimum number of required approvers can still be set in the [project settings f You can opt to define one single rule to approve a merge request among the available rules or choose more than one. Single approval rules are available in GitLab Starter and higher tiers, -while [multiple approval rules](#multiple-approval-rules-premium) are available in +while [multiple approval rules](#multiple-approval-rules) are available in [GitLab Premium](https://about.gitlab.com/pricing/) and above. NOTE: **Note:** @@ -119,7 +119,7 @@ users with Developer or higher permissions, as well as by Code Owners, indistinguishably. Alternatively, you can **require** -[Code Owner's approvals for Protected Branches](../protected_branches.md#protected-branches-approval-by-code-owners-premium). **(PREMIUM)** +[Code Owner's approvals for Protected Branches](../protected_branches.md#protected-branches-approval-by-code-owners). **(PREMIUM)** #### Adding / editing a default approval rule @@ -205,7 +205,7 @@ Alternatively, you can select a very specific protected branch from the **Target  -To enable this configuration, see [Code Owner’s approvals for protected branches](../protected_branches.md#protected-branches-approval-by-code-owners-premium). +To enable this configuration, see [Code Owner’s approvals for protected branches](../protected_branches.md#protected-branches-approval-by-code-owners). ### Adding or removing an approval diff --git a/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md b/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md index 4e821145339..f60be893e45 100644 --- a/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md +++ b/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md @@ -73,7 +73,7 @@ list. > - It's deployed behind a feature flag, enabled by default. > - It's recommended for production use. > - It's enabled on GitLab.com. -> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-file-by-file-diff-navigation-core-only). +> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-file-by-file-diff-navigation). For larger merge requests it might sometimes be useful to review single files at a time. To enable, from your avatar on the top-right navbar, click **Settings**, and go to **Preferences** on the left @@ -156,7 +156,7 @@ in a Merge Request. To do so, click the **{comment}** **comment** icon in the gu > - It's enabled on GitLab.com. > - It can be disabled or enabled per-project. > - It's recommended for production use. -> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-multiline-comments-core-only). **(CORE ONLY)** +> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-multiline-comments). **(CORE ONLY)** GitLab provides a way to select which lines of code a comment refers to. After starting a comment a dropdown selector is shown to select the first line that this comment refers to. diff --git a/doc/user/project/merge_requests/squash_and_merge.md b/doc/user/project/merge_requests/squash_and_merge.md index ef49a026c99..69a0dd6e84f 100644 --- a/doc/user/project/merge_requests/squash_and_merge.md +++ b/doc/user/project/merge_requests/squash_and_merge.md @@ -110,7 +110,7 @@ squashing can itself be considered equivalent to rebasing. > - It's enabled on GitLab.com. > - It can be enabled per project. > - It's recommended for production use. -> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-squash-commit-options-core-only). **(CORE ONLY)** +> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-squash-commit-options). **(CORE ONLY)** With Squash Commits Options you can configure the behavior of Squash and Merge for your project. To set it up, navigate to your project's **Settings > General** and expand **Merge requests**. diff --git a/doc/user/project/milestones/index.md b/doc/user/project/milestones/index.md index 1347731fb28..9d02a22f91e 100644 --- a/doc/user/project/milestones/index.md +++ b/doc/user/project/milestones/index.md @@ -117,9 +117,9 @@ From the project issue/merge request list pages and the group issue/merge reques ### Filtering in issue boards - From [project issue boards](../issue_board.md), you can filter by both group milestones and project milestones in the [search and filter bar](../../search/index.md#issue-boards). -- From [group issue boards](../issue_board.md#group-issue-boards-premium), you can filter by only group milestones in the [search and filter bar](../../search/index.md#issue-boards). **(PREMIUM)** -- From [project issue boards](../issue_board.md), you can filter by both group milestones and project milestones in the [issue board configuration](../issue_board.md#configurable-issue-boards-starter). **(STARTER)** -- From [group issue boards](../issue_board.md#group-issue-boards-premium) you can filter by only group milestones in the [issue board configuration](../issue_board.md#configurable-issue-boards-starter). **(STARTER)** +- From [group issue boards](../issue_board.md#group-issue-boards), you can filter by only group milestones in the [search and filter bar](../../search/index.md#issue-boards). **(PREMIUM)** +- From [project issue boards](../issue_board.md), you can filter by both group milestones and project milestones in the [issue board configuration](../issue_board.md#configurable-issue-boards). **(STARTER)** +- From [group issue boards](../issue_board.md#group-issue-boards) you can filter by only group milestones in the [issue board configuration](../issue_board.md#configurable-issue-boards). **(STARTER)** ### Special milestone filters diff --git a/doc/user/project/new_ci_build_permissions_model.md b/doc/user/project/new_ci_build_permissions_model.md index cfcbf11a407..a9d2c813f93 100644 --- a/doc/user/project/new_ci_build_permissions_model.md +++ b/doc/user/project/new_ci_build_permissions_model.md @@ -54,7 +54,7 @@ It is important to note that we have a few types of users: Administrator will have to be a member of it in order to have access to it via another project's job. -- **External users**: CI jobs created by [external users](../permissions.md#external-users-core-only) will have +- **External users**: CI jobs created by [external users](../permissions.md#external-users) will have access only to projects to which the user has at least Reporter access. This rules out accessing all internal projects by default. @@ -65,7 +65,7 @@ Let's consider the following scenario: hosted in private repositories and you have multiple CI jobs that make use of these repositories. -1. You invite a new [external user](../permissions.md#external-users-core-only). CI jobs created by that user do not +1. You invite a new [external user](../permissions.md#external-users). CI jobs created by that user do not have access to internal repositories, because the user also doesn't have the access from within GitLab. You as an employee have to grant explicit access for this user. This allows us to prevent from accidental data leakage. diff --git a/doc/user/project/releases/index.md b/doc/user/project/releases/index.md index 003959ab086..a06a684c7e6 100644 --- a/doc/user/project/releases/index.md +++ b/doc/user/project/releases/index.md @@ -329,7 +329,7 @@ internal processes, like external audits. To access the release evidence, on the Releases page, click the link to the JSON file that's listed under the **Evidence collection** heading. -You can also [use the API](../../../api/releases/index.md#collect-release-evidence-premium-only) to +You can also [use the API](../../../api/releases/index.md#collect-release-evidence) to generate release evidence for an existing release. Because of this, each release can have multiple release evidence snapshots. You can view the release evidence and its details on the Releases page. @@ -401,7 +401,7 @@ Here is an example of a release evidence object: > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/199065) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.10. -When a release is created, release evidence is automatically collected. To initiate evidence collection any other time, use an [API call](../../../api/releases/index.md#collect-release-evidence-premium-only). You can collect release evidence multiple times for one release. +When a release is created, release evidence is automatically collected. To initiate evidence collection any other time, use an [API call](../../../api/releases/index.md#collect-release-evidence). You can collect release evidence multiple times for one release. Evidence collection snapshots are visible on the Releases page, along with the timestamp the evidence was collected. diff --git a/doc/user/project/repository/branches/index.md b/doc/user/project/repository/branches/index.md index 54979d1c4ce..a937b6ed959 100644 --- a/doc/user/project/repository/branches/index.md +++ b/doc/user/project/repository/branches/index.md @@ -60,7 +60,7 @@ against accidental deletion and forced pushes. > - It's enabled on GitLab.com. > - It cannot be enabled or disabled per-project. > - It's recommended for production use. -> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-custom-initial-branch-name-core-only). **(CORE ONLY)** +> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-custom-initial-branch-name). **(CORE ONLY)** By default, when you create a new project in GitLab, the initial branch is called `master`. For self-managed instances, a GitLab administrator can customize the initial branch name to something diff --git a/doc/user/project/repository/reducing_the_repo_size_using_git.md b/doc/user/project/repository/reducing_the_repo_size_using_git.md index 1fee73e72ad..7e7716569b8 100644 --- a/doc/user/project/repository/reducing_the_repo_size_using_git.md +++ b/doc/user/project/repository/reducing_the_repo_size_using_git.md @@ -252,7 +252,7 @@ When using repository cleanup, note: Repository size limits: -- Can [be set by an administrator](../../admin_area/settings/account_and_limit_settings.md#repository-size-limit-starter-only) +- Can [be set by an administrator](../../admin_area/settings/account_and_limit_settings.md#repository-size-limit) on self-managed instances. **(STARTER ONLY)** - Are [set for GitLab.com](../../gitlab_com/index.md#repository-size-limit). diff --git a/doc/user/project/repository/repository_mirroring.md b/doc/user/project/repository/repository_mirroring.md index 76ac221a295..9c644a1690e 100644 --- a/doc/user/project/repository/repository_mirroring.md +++ b/doc/user/project/repository/repository_mirroring.md @@ -72,7 +72,7 @@ When push mirroring is enabled, only push commits directly to the mirrored repos mirror diverging. All changes will end up in the mirrored repository whenever: - Commits are pushed to GitLab. -- A [forced update](#forcing-an-update-core) is initiated. +- A [forced update](#forcing-an-update) is initiated. Changes pushed to files in the repository are automatically pushed to the remote mirror at least: @@ -252,7 +252,7 @@ directly to the repository on GitLab. Instead, any commits should be pushed to t Changes pushed to the upstream repository will be pulled into the GitLab repository, either: - Automatically within a certain period of time. -- When a [forced update](#forcing-an-update-core) is initiated. +- When a [forced update](#forcing-an-update) is initiated. CAUTION: **Caution:** If you do manually update a branch in the GitLab repository, the branch will become diverged from @@ -398,17 +398,17 @@ failed. This will become visible in either the: - Pull mirror settings page. When a project is hard failed, it will no longer get picked up for mirroring. A user can resume the -project mirroring again by [Forcing an update](#forcing-an-update-core). +project mirroring again by [Forcing an update](#forcing-an-update). ### Trigger update using API **(STARTER)** > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3453) in [GitLab Starter](https://about.gitlab.com/pricing/) 10.3. Pull mirroring uses polling to detect new branches and commits added upstream, often minutes -afterwards. If you notify GitLab by [API](../../../api/projects.md#start-the-pull-mirroring-process-for-a-project-starter), +afterwards. If you notify GitLab by [API](../../../api/projects.md#start-the-pull-mirroring-process-for-a-project), updates will be pulled immediately. -For more information, see [Start the pull mirroring process for a Project](../../../api/projects.md#start-the-pull-mirroring-process-for-a-project-starter). +For more information, see [Start the pull mirroring process for a Project](../../../api/projects.md#start-the-pull-mirroring-process-for-a-project). ## Forcing an update **(CORE)** @@ -430,8 +430,8 @@ them and how they will be resolved. Rewriting any mirrored commit on either remote will cause conflicts and mirroring to fail. This can be prevented by: -- [Pulling only protected branches](#only-mirror-protected-branches-starter). -- [Pushing only protected branches](#push-only-protected-branches-core). +- [Pulling only protected branches](#only-mirror-protected-branches). +- [Pushing only protected branches](#push-only-protected-branches). You should [protect the branches](../protected_branches.md) you wish to mirror on both remotes to prevent conflicts caused by rewriting history. @@ -444,13 +444,13 @@ protected branches. ### Configure a webhook to trigger an immediate pull to GitLab -Assuming you have already configured the [push](#setting-up-a-push-mirror-to-another-gitlab-instance-with-2fa-activated) and [pull](#pulling-from-a-remote-repository-starter) mirrors in the upstream GitLab instance, to trigger an immediate pull as suggested above, you will need to configure a [Push Event Web Hook](../integrations/webhooks.md#push-events) in the downstream instance. +Assuming you have already configured the [push](#setting-up-a-push-mirror-to-another-gitlab-instance-with-2fa-activated) and [pull](#pulling-from-a-remote-repository) mirrors in the upstream GitLab instance, to trigger an immediate pull as suggested above, you will need to configure a [Push Event Web Hook](../integrations/webhooks.md#push-events) in the downstream instance. To do this: - Create a [personal access token](../../profile/personal_access_tokens.md) with `API` scope. - Navigate to **Settings > Webhooks** -- Add the webhook URL which in this case will use the [Pull Mirror API](../../../api/projects.md#start-the-pull-mirroring-process-for-a-project-starter) request to trigger an immediate pull after updates to the repository. +- Add the webhook URL which in this case will use the [Pull Mirror API](../../../api/projects.md#start-the-pull-mirroring-process-for-a-project) request to trigger an immediate pull after updates to the repository. ```plaintext https://gitlab.example.com/api/v4/projects/:id/mirror/pull?private_token=<your_access_token> diff --git a/doc/user/project/requirements/index.md b/doc/user/project/requirements/index.md index ae22dbc7e72..9d7d3914905 100644 --- a/doc/user/project/requirements/index.md +++ b/doc/user/project/requirements/index.md @@ -95,7 +95,7 @@ You can also sort the requirements list by: > - [Added](https://gitlab.com/gitlab-org/gitlab/-/issues/215514) ability to specify individual requirements and their statuses in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.2. GitLab supports [requirements test -reports](../../../ci/pipelines/job_artifacts.md#artifactsreportsrequirements-ultimate) now. +reports](../../../ci/pipelines/job_artifacts.md#artifactsreportsrequirements) now. You can add a job to your CI pipeline that, when triggered, marks all existing requirements as Satisfied. diff --git a/doc/user/project/settings/index.md b/doc/user/project/settings/index.md index f5be0881a29..3be54a5c940 100644 --- a/doc/user/project/settings/index.md +++ b/doc/user/project/settings/index.md @@ -78,7 +78,7 @@ Some features depend on others: - If you disable the **Issues** option, GitLab also removes the following features: - **Issue Boards** - - [**Service Desk**](#service-desk-starter) + - [**Service Desk**](#service-desk) NOTE: **Note:** When the **Issues** option is disabled, you can still access **Milestones** @@ -237,10 +237,10 @@ This action: - 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](../../group/index.md#enabling-delayed-project-removal-premium) projects within a group +group admins can [configure](../../group/index.md#enabling-delayed-project-removal) projects within a group to be deleted after a delayed period. When enabled, actual deletion happens after number of days -specified in [instance settings](../../admin_area/settings/visibility_and_access_controls.md#default-deletion-delay-premium-only). +specified in [instance settings](../../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 diff --git a/doc/user/project/web_ide/index.md b/doc/user/project/web_ide/index.md index 12ba55cafdc..d79e5a184ff 100644 --- a/doc/user/project/web_ide/index.md +++ b/doc/user/project/web_ide/index.md @@ -59,7 +59,7 @@ Single file editing is based on the [Ace Editor](https://ace.c9.io). > - It was deployed behind a feature flag, disabled by default. > - It's enabled on GitLab.com. > - It cannot be enabled or disabled per-project. -> - For GitLab self-managed instances, GitLab administrators can opt to [enable it](#enable-or-disable-schema-based-validation-core-only). +> - For GitLab self-managed instances, GitLab administrators can opt to [enable it](#enable-or-disable-schema-based-validation). The Web IDE provides validation support for certain JSON and YAML files using schemas based on the [JSON Schema Store](https://www.schemastore.org/json/). This feature is diff --git a/doc/user/project/wiki/index.md b/doc/user/project/wiki/index.md index 5503cd97628..40ef5e216fd 100644 --- a/doc/user/project/wiki/index.md +++ b/doc/user/project/wiki/index.md @@ -165,7 +165,7 @@ Similar to versioned diff file views, you can see the changes made in a given Wi > - Git events were [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/216014) in **GitLab 13.0.** > - It's enabled on GitLab.com. > - Git access activity creation is managed by a feature flag. -> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-wiki-events-in-git-core-only). **(CORE ONLY)** +> - To use it in GitLab self-managed instances, ask a GitLab administrator to [enable it](#enable-or-disable-wiki-events-in-git). **(CORE ONLY)** Wiki events (creation, deletion, and updates) are tracked by GitLab and displayed on the [user profile](../../profile/index.md#user-profile), diff --git a/doc/user/search/index.md b/doc/user/search/index.md index 12b7b0adba9..27538034e1d 100644 --- a/doc/user/search/index.md +++ b/doc/user/search/index.md @@ -49,7 +49,7 @@ groups: - My-reaction - Confidential - Epic ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/195704) in GitLab 12.9), - including [child epic](../group/epics/index.md#multi-level-child-epics-ultimate) + including [child epic](../group/epics/index.md#multi-level-child-epics) ([introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9029) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.0) - Search for this text |