diff options
Diffstat (limited to 'doc/user/admin_area')
28 files changed, 233 insertions, 141 deletions
diff --git a/doc/user/admin_area/analytics/dev_ops_report.md b/doc/user/admin_area/analytics/dev_ops_report.md index 6ca5e5034bf..89d8a5ea054 100644 --- a/doc/user/admin_area/analytics/dev_ops_report.md +++ b/doc/user/admin_area/analytics/dev_ops_report.md @@ -20,46 +20,49 @@ To see DevOps Report: ## DevOps Score NOTE: -Your GitLab instance's [usage ping](../settings/usage_statistics.md#usage-ping) must be activated in order to use this feature. +To see the DevOps score, you must activate your GitLab instance's [Service Ping](../settings/usage_statistics.md#service-ping). -The DevOps Score tab displays the usage of major GitLab features on your instance over -the last 30 days, averaged over the number of billable users in that time period. It also -provides a Lead score per feature, which is calculated based on GitLab analysis -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. - -The page also provides helpful links to articles and GitLab docs, to help you -improve your scores. +You can use the DevOps score to compare your DevOps status to other organizations. -Usage ping data is aggregated on GitLab servers for analysis. Your usage -information is **not sent** to any other GitLab instances. If you have just started using GitLab, it may take a few weeks for data to be -collected before this feature is available. +The DevOps Score tab displays the usage of major GitLab features on your instance over +the last 30 days, averaged over the number of billable users in that time period. +You can also see the Leader usage score, calculated from top-performing instances based on +[Service Ping data](../settings/usage_statistics.md#service-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. + +Service Ping data is aggregated on GitLab servers for analysis. Your usage +information is **not sent** to any other GitLab instances. +If you have just started using GitLab, it might take a few weeks for data to be collected before this +feature is available. ## DevOps Adoption **(ULTIMATE SELF)** -> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/247112) in GitLab 13.7 as a [Beta feature](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta) +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/247112) in GitLab 13.7 as a [Beta feature](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta). > - [Deployed behind a feature flag](../../../user/feature_flags.md), disabled by default. > - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/59267) in GitLab 14.0. > - Enabled on GitLab.com. > - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#disable-or-enable-devops-adoption). **(ULTIMATE SELF)** +> - The Overview tab [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/330401) in GitLab 14.1. +> - DAST and SAST metrics [added](https://gitlab.com/gitlab-org/gitlab/-/issues/328033) in GitLab 14.1. -The DevOps Adoption tab shows you which groups within your organization are using the most essential features of GitLab: +DevOps Adoption shows you which groups in your organization are using the most essential features of GitLab: - Dev - - Issues - - Merge Requests - Approvals - Code owners + - Issues + - Merge requests - Sec - - Scans + - DAST + - SAST - Ops - - Runners - - Pipelines - Deployments + - Pipelines + - Runners -When managing groups in the UI, you can add your groups with the **Add group to table** -button, in the top right hand section the page. +To add your groups, in the top right-hand section the page, select **Add group to table**. DevOps Adoption allows you to: @@ -67,7 +70,7 @@ DevOps Adoption allows you to: - Identify specific groups that are lagging in their adoption of GitLab so you can help them along in their DevOps journey. - Find the groups that have adopted certain features and can provide guidance to other groups on how to use those features. - + ### Disable or enable DevOps Adoption diff --git a/doc/user/admin_area/analytics/img/admin_devops_adoption_v14_0.png b/doc/user/admin_area/analytics/img/admin_devops_adoption_v14_0.png Binary files differdeleted file mode 100644 index f4170b2938c..00000000000 --- a/doc/user/admin_area/analytics/img/admin_devops_adoption_v14_0.png +++ /dev/null diff --git a/doc/user/admin_area/analytics/img/admin_devops_adoption_v14_1.png b/doc/user/admin_area/analytics/img/admin_devops_adoption_v14_1.png Binary files differnew file mode 100644 index 00000000000..79481e43e8e --- /dev/null +++ b/doc/user/admin_area/analytics/img/admin_devops_adoption_v14_1.png diff --git a/doc/user/admin_area/analytics/user_cohorts.md b/doc/user/admin_area/analytics/user_cohorts.md deleted file mode 100644 index b906f9b8fa6..00000000000 --- a/doc/user/admin_area/analytics/user_cohorts.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -redirect_to: '../user_cohorts.md' -remove_date: '2021-06-01' ---- - -This document was moved to [another location](../user_cohorts.md). - -<!-- This redirect file can be deleted after <2021-06-01>. --> -<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page --> diff --git a/doc/user/admin_area/approving_users.md b/doc/user/admin_area/approving_users.md index 3d9722035d5..2852f73ffc8 100644 --- a/doc/user/admin_area/approving_users.md +++ b/doc/user/admin_area/approving_users.md @@ -47,7 +47,8 @@ To approve or reject a user sign up: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. On the left sidebar, select **Overview > Users**. 1. Select the **Pending approval** tab. -1. In the user's row, select settings (**{settings}**). +1. (Optional) Select a user. +1. Select the **{settings}** **User administration** dropdown. 1. Select **Approve** or **Reject**. Approving a user: diff --git a/doc/user/admin_area/credentials_inventory.md b/doc/user/admin_area/credentials_inventory.md index dfb37cb8646..8c5ae2dfb47 100644 --- a/doc/user/admin_area/credentials_inventory.md +++ b/doc/user/admin_area/credentials_inventory.md @@ -38,7 +38,7 @@ The following is an example of the Credentials inventory page: If you see a **Revoke** button, you can revoke that user's PAT. Whether you see a **Revoke** button depends on the token state, and if an expiration date has been set. For more information, see the following table: -| Token state | [Token expiration enforced?](settings/account_and_limit_settings.md#do-not-enforce-personal-access-token-expiration) | Show Revoke button? | Comments | +| Token state | [Token expiration enforced?](settings/account_and_limit_settings.md#allow-expired-personal-access-tokens-to-be-used) | Show Revoke button? | Comments | |-------------|------------------------|--------------------|----------------------------------------------------------------------------| | Active | Yes | Yes | Allows administrators to revoke the PAT, such as for a compromised account | | Active | No | Yes | Allows administrators to revoke the PAT, such as for a compromised account | diff --git a/doc/user/admin_area/custom_project_templates.md b/doc/user/admin_area/custom_project_templates.md index 6cf3c5bbd7d..12d143b3a13 100644 --- a/doc/user/admin_area/custom_project_templates.md +++ b/doc/user/admin_area/custom_project_templates.md @@ -9,36 +9,33 @@ type: reference > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/6860) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.2. -GitLab administrators can configure the group where all the custom project -templates are sourced. +GitLab administrators can set a group to be the source of project templates that are +selectable when a new project is created on the instance. These templates can be selected +when you go to **New project > Create from template** and select the **Instance** tab. -Every project directly under the group namespace will be -available to the user if they have access to them. For example: +Every project in the group, but not its subgroups, can be selected when a new project +is created, based on the user's access permissions: -- Public projects, in the group will be available to every signed-in user, if all enabled [project features](../project/settings/index.md#sharing-and-permissions) +- Public projects can be selected by any signed-in user as a template for a new project, + if all enabled [project features](../project/settings/index.md#sharing-and-permissions) except for GitLab Pages are set to **Everyone With Access**. -- Private projects will be available only if the user is a member of the project. +- Private projects can be selected only by users who are members of the projects. Repository and database information that are copied over to each new project are -identical to the data exported with the -[GitLab Project Import/Export](../project/settings/import_export.md). +identical to the data exported with the [GitLab Project Import/Export](../project/settings/import_export.md). -NOTE: -To set project templates at a group level, -see [Custom group-level project templates](../group/custom_project_templates.md). +To set project templates at the group level, see [Custom group-level project templates](../group/custom_project_templates.md). -## Configuring +## Select instance-level project template group -GitLab administrators can configure a GitLab group that serves as template -source for an entire GitLab instance: +To select the group to use as the source for the project templates: 1. On the top bar, navigate to **Menu > Admin > Settings > Templates**. 1. Expand **Custom project templates**. 1. Select a group to use. 1. Select **Save changes**. -NOTE: -Projects below subgroups of the template group are **not** supported. +Projects in subgroups of the template group are **not** included in the template list. <!-- ## Troubleshooting diff --git a/doc/user/admin_area/diff_limits.md b/doc/user/admin_area/diff_limits.md index 37fdb3ae195..4be1ace10aa 100644 --- a/doc/user/admin_area/diff_limits.md +++ b/doc/user/admin_area/diff_limits.md @@ -21,10 +21,11 @@ consumption of your instance. Keep this in mind when adjusting the maximum. To speed the loading time of merge request views and branch comparison views on your instance, you can configure three instance-level maximum values for diffs: -- **Maximum diff patch size**: The total size, in bytes, of the entire diff. -- **Maximum diff files**: The total number of files changed in a diff. -- **Maximum diff files**: The total number of files changed in a diff. The default value is 1000. -- **Maximum diff lines**: The total number of lines changed in a diff. The default value is 50,000. +| Value | Definition | Default value | Maximum value | +| ----- | ---------- | :-----------: | :-----------: | +| **Maximum diff patch size** | The total size, in bytes, of the entire diff. | 200 KB | 500 KB | +| **Maximum diff files** | The total number of files changed in a diff. | 1000 | 3000 | +| **Maximum diff lines** | The total number of lines changed in a diff. | 50,000 | 100,000 | When a diff reaches 10% of any of these values, the files are shown in a collapsed view, with a link to expand the diff. Diffs that exceed any of the @@ -35,7 +36,7 @@ To configure these values: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. In the left sidebar, select **Settings > General**. 1. Expand **Diff limits**. -1. Enter a value for **Maximum diff patch size**, measured in bytes. +1. Enter a value for the diff limit. 1. Select **Save changes**. <!-- ## Troubleshooting diff --git a/doc/user/admin_area/img/index_runners_search_or_filter.png b/doc/user/admin_area/img/index_runners_search_or_filter.png Binary files differdeleted file mode 100644 index 5176a1a39bf..00000000000 --- a/doc/user/admin_area/img/index_runners_search_or_filter.png +++ /dev/null diff --git a/doc/user/admin_area/img/index_runners_search_or_filter_v14_1.png b/doc/user/admin_area/img/index_runners_search_or_filter_v14_1.png Binary files differnew file mode 100644 index 00000000000..ab196a0ca9e --- /dev/null +++ b/doc/user/admin_area/img/index_runners_search_or_filter_v14_1.png diff --git a/doc/user/admin_area/index.md b/doc/user/admin_area/index.md index 2e4a8261c63..31fd1a3a0a1 100644 --- a/doc/user/admin_area/index.md +++ b/doc/user/admin_area/index.md @@ -160,7 +160,7 @@ You can impersonate a user in the following ways: 1. In the left sidebar, select **Overview > Users**. 1. From the list of users, select a user. 1. Select **Impersonate**. -- With the API, using [impersonation tokens](../../api/README.md#impersonation-tokens). +- With the API, using [impersonation tokens](../../api/index.md#impersonation-tokens). All impersonation activities are [captured with audit events](../../administration/audit_events.md#impersonation-data). @@ -276,21 +276,22 @@ To search runners' descriptions: You can also filter runners by status, type, and tag. To filter: 1. Click in the **Search or filter results...** field. -1. Select **status:**, **type:**, or **tag:**. +1. Select **Status**, **Type**, or **Tags**. 1. Select or enter your search criteria. - + For each runner, the following attributes are listed: | Attribute | Description | |--------------|-------------| -| Type | One or more of the following states: shared, group, specific, locked, or paused | -| Runner token | Token used to identify the runner, and which the runner uses to communicate with the GitLab instance | -| Description | Description given to the runner when it was created | +| Type/State | One or more of the following states: shared, group, specific, locked, or paused | +| Runner token | Partial token used to identify the runner, and which the runner uses to communicate with the GitLab instance | +| Runner ID | Numerical ID of the runner | +| Description | Description given to the runner | | Version | GitLab Runner version | | IP address | IP address of the host on which the runner is registered | -| Projects | Projects to which the runner is assigned | +| Projects | Number of projects to which the runner is assigned | | Jobs | Total of jobs run by the runner | | Tags | Tags associated with the runner | | Last contact | Timestamp indicating when the runner last contacted the GitLab instance | diff --git a/doc/user/admin_area/license.md b/doc/user/admin_area/license.md index 58876b87576..57f643b75c7 100644 --- a/doc/user/admin_area/license.md +++ b/doc/user/admin_area/license.md @@ -107,7 +107,7 @@ For GitLab self-managed instances, you have a 14-day grace period before this occurs. - To resume functionality, upload a new license. -- To fall back to Free features, delete the expired license. +- To fall back to Free features, delete all expired licenses. ### Remove a license @@ -117,6 +117,8 @@ To remove a license from a self-managed instance: 1. On the left sidebar, select **License**. 1. Select **Remove license**. +These steps may need to be repeated to completely remove all licenses, including those applied in the past. + ## License history You can upload and view more than one license, but only the latest license in the current date diff --git a/doc/user/admin_area/moderate_users.md b/doc/user/admin_area/moderate_users.md index 71e72cc630c..3889dd93d59 100644 --- a/doc/user/admin_area/moderate_users.md +++ b/doc/user/admin_area/moderate_users.md @@ -23,8 +23,9 @@ or directly from the Admin Area. To do this: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. On the left sidebar, select **Overview > Users**. -1. Select a user. -1. Under the **Account** tab, select **Block user**. +1. (Optional) Select a user. +1. Select the **{settings}** **User administration** dropdown. +1. Select **Block**. A blocked user: @@ -47,8 +48,9 @@ A blocked user can be unblocked from the Admin Area. To do this: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. On the left sidebar, select **Overview > Users**. 1. Select on the **Blocked** tab. -1. Select a user. -1. Under the **Account** tab, select **Unblock user**. +1. (Optional) Select a user. +1. Select the **{settings}** **User administration** dropdown. +1. Select **Unblock**. Users can also be unblocked using the [GitLab API](../../api/users.md#unblock-user). @@ -85,8 +87,9 @@ A user can be deactivated from the Admin Area. To do this: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. On the left sidebar, select **Overview > Users**. -1. Select a user. -1. Under the **Account** tab, select **Deactivate user**. +1. (Optional) Select a user. +1. Select the **{settings}** **User administration** dropdown. +1. Select **Deactivate**. Please note that for the deactivation option to be visible to an admin, the user: @@ -126,8 +129,9 @@ To do this: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. On the left sidebar, select **Overview > Users**. 1. Select the **Deactivated** tab. -1. Select a user. -1. Under the **Account** tab, select **Activate user**. +1. (Optional) Select a user. +1. Select the **{settings}** **User administration** dropdown. +1. Select **Activate**. Users can also be activated using the [GitLab API](../../api/users.md#activate-user). @@ -145,7 +149,7 @@ A deactivated user can also activate their account themselves by logging back in GitLab administrators can ban users. NOTE: -This feature is behind a feature flag that is disabled by default. GitLab administrators +This feature is behind a feature flag that is disabled by default. GitLab administrators with access to the GitLab Rails console can [enable](../../administration/feature_flags.md) this feature for your GitLab instance. @@ -157,8 +161,9 @@ Users can be banned using the Admin Area. To do this: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. On the left sidebar, select **Overview > Users**. -1. Select a user. -1. Under the **Account** tab, select **Ban user**. +1. (Optional) Select a user. +1. Select the **{settings}** **User administration** dropdown. +1. Select **Ban user**. NOTE: This feature is a work in progress. Currently, banning a user @@ -172,8 +177,9 @@ A banned user can be unbanned using the Admin Area. To do this: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. On the left sidebar, select **Overview > Users**. 1. Select the **Banned** tab. -1. Select a user. -1. Under the **Account** tab, select **Unban user**. +1. (Optional) Select a user. +1. Select the **{settings}** **User administration** dropdown. +1. Select **Unban user**. NOTE: Unbanning a user changes the user's state to active and consumes a diff --git a/doc/user/admin_area/monitoring/background_migrations.md b/doc/user/admin_area/monitoring/background_migrations.md index 50593959710..cbaa4b30cb7 100644 --- a/doc/user/admin_area/monitoring/background_migrations.md +++ b/doc/user/admin_area/monitoring/background_migrations.md @@ -4,7 +4,7 @@ group: Database info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments --- -# Batched Background Migrations **(FREE SELF)** +# Batched background migrations **(FREE SELF)** > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/51332) in GitLab 13.11. > - [Deployed behind a feature flag](../../../user/feature_flags.md), disabled by default. @@ -21,16 +21,19 @@ are created by GitLab developers and run automatically on upgrade. However, such limited in scope to help with migrating some `integer` database columns to `bigint`. This is needed to prevent integer overflow for some tables. -All migrations must be finished before upgrading GitLab. To check the status of the existing -migrations, execute this command: +## Check the status of background migrations **(FREE SELF)** -```ruby -Gitlab::Database::BackgroundMigration::BatchedMigration.pluck(:id, :table_name, :status) -``` +All migrations must have a `Finished` status before updating GitLab. To check the status of the existing +migrations: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. On the left sidebar, select **Monitoring > Background Migrations**. + +  -## Enable or disable Batched Background Migrations **(FREE SELF)** +## Enable or disable batched background migrations **(FREE SELF)** -Batched Background Migrations is under development but ready for production use. +Batched background migrations are under development but ready for production use. It is deployed behind a feature flag that is **enabled by default**. [GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md) can opt to disable it. @@ -63,7 +66,7 @@ To maximize throughput of batched background migrations (in terms of the number ## Enable or disable automatic batch size optimization **(FREE SELF)** -Automatic batch size optimization for Batched Background Migrations is under development but ready for production use. +Automatic batch size optimization for batched background migrations is under development but ready for production use. It is deployed behind a feature flag that is **enabled by default**. [GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md) can opt to disable it. @@ -79,3 +82,27 @@ To disable it: ```ruby Feature.disable(:optimize_batched_migrations) ``` + +## Troubleshooting + +### Database migrations failing because of batched background migration not finished + +When updating to GitLab 14.2 or later there might be a database migration failing with a message like: + +```plaintext +StandardError: An error has occurred, all later migrations canceled: + +Expected batched background migration for the given configuration to be marked as 'finished', but it is 'active': + {:job_class_name=>"CopyColumnUsingBackgroundMigrationJob", :table_name=>"push_event_payloads", :column_name=>"event_id", :job_arguments=>[["event_id"], ["event_id_convert_to_bigint"]]} +``` + +To fix this error: + +1. Update to either 14.0.5 or 14.1. +1. [Check the status](#check-the-status-of-background-migrations) of the batched background migration from the error message, and make sure it is listed as finished. If it is still active, either wait until it is done, or finalize it manually using the command suggested in the error, for example: + +```shell +sudo gitlab-rake gitlab:background_migrations:finalize[CopyColumnUsingBackgroundMigrationJob,push_event_payloads,event_id,'[["event_id"]\, ["event_id_convert_to_bigint"]]'] +``` + +1. You can now update to GitLab 14.2 or higher. diff --git a/doc/user/admin_area/monitoring/img/batched_background_migrations_queued_v14_0.png b/doc/user/admin_area/monitoring/img/batched_background_migrations_queued_v14_0.png Binary files differnew file mode 100644 index 00000000000..0b0792b5e7a --- /dev/null +++ b/doc/user/admin_area/monitoring/img/batched_background_migrations_queued_v14_0.png diff --git a/doc/user/admin_area/review_abuse_reports.md b/doc/user/admin_area/review_abuse_reports.md index a179eb70453..7816d0648b2 100644 --- a/doc/user/admin_area/review_abuse_reports.md +++ b/doc/user/admin_area/review_abuse_reports.md @@ -14,7 +14,7 @@ reports in the Admin Area. ## Receiving notifications of abuse reports -To receive notifications of new abuse reports by e-mail, follow these steps: +To receive notifications of new abuse reports by email, follow these steps: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. On the left sidebar, select **Settings > Reporting**. 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 f2a849e1894..2b60ed5345b 100644 --- a/doc/user/admin_area/settings/account_and_limit_settings.md +++ b/doc/user/admin_area/settings/account_and_limit_settings.md @@ -199,7 +199,7 @@ Once a lifetime for personal access tokens is set, GitLab: allowed lifetime. Three hours is given to allow administrators to change the allowed lifetime, or remove it, before revocation takes place. -## Enforce SSH key expiration **(ULTIMATE SELF)** +## Allow expired SSH keys to be used **(ULTIMATE SELF)** > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/250480) in GitLab 13.9. > - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/320970) in GitLab 14.0. @@ -215,15 +215,14 @@ To allow the use of expired SSH keys: Disabling SSH key expiration immediately enables all expired SSH keys. -## Do not enforce Personal Access Token expiration **(ULTIMATE SELF)** +## Allow expired Personal Access Tokens to be used **(ULTIMATE SELF)** > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214723) in GitLab Ultimate 13.1. > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/296881) in GitLab 13.9. -By default, expired personal access tokens (PATs) cannot be used. -You can allow the use of expired PATs with the following steps: +By default, expired personal access tokens (PATs) **are not usable**. -To do this: +To allow the use of expired PATs: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. In the left sidebar, select **Settings > General**. diff --git a/doc/user/admin_area/settings/continuous_integration.md b/doc/user/admin_area/settings/continuous_integration.md index ffe969a6799..69d86259409 100644 --- a/doc/user/admin_area/settings/continuous_integration.md +++ b/doc/user/admin_area/settings/continuous_integration.md @@ -88,7 +88,7 @@ The setting at all levels is only available to GitLab administrators. The default expiration time of the [job artifacts](../../../administration/job_artifacts.md) can be set in the Admin Area of your GitLab instance. The syntax of duration is -described in [`artifacts:expire_in`](../../../ci/yaml/README.md#artifactsexpire_in) +described in [`artifacts:expire_in`](../../../ci/yaml/index.md#artifactsexpire_in) and the default value is `30 days`. 1. On the top bar, select **Menu >** **{admin}** **Admin**. @@ -97,7 +97,7 @@ and the default value is `30 days`. 1. Click **Save changes** for the changes to take effect. This setting is set per job and can be overridden in -[`.gitlab-ci.yml`](../../../ci/yaml/README.md#artifactsexpire_in). +[`.gitlab-ci.yml`](../../../ci/yaml/index.md#artifactsexpire_in). To disable the expiration, set it to `0`. The default unit is in seconds. NOTE: @@ -195,8 +195,8 @@ As of June 22, 2020 the [value is set](../../gitlab_com/index.md#gitlab-cicd) to ## Protect CI/CD variables by default -To set all new [CI/CD variables](../../../ci/variables/README.md) as -[protected](../../../ci/variables/README.md#protect-a-cicd-variable) by default: +To set all new [CI/CD variables](../../../ci/variables/index.md) as +[protected](../../../ci/variables/index.md#protect-a-cicd-variable) by default: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. On the left sidebar, select **Settings > CI/CD**. @@ -214,7 +214,7 @@ of your GitLab instance (`.gitlab-ci.yml` if not set): 1. Input the new file and path in the **Default CI/CD configuration file** field. 1. Hit **Save changes** for the changes to take effect. -It is also possible to specify a [custom CI/CD configuration file for a specific project](../../../ci/pipelines/settings.md#custom-cicd-configuration-file). +It is also possible to specify a [custom CI/CD configuration file for a specific project](../../../ci/pipelines/settings.md#specify-a-custom-cicd-configuration-file). ## Required pipeline configuration **(PREMIUM SELF)** @@ -224,7 +224,7 @@ This feature is being re-evaluated in favor of a different We recommend that users who haven't yet implemented this feature wait for the new solution. -You can set a [CI/CD template](../../../ci/examples/README.md#cicd-templates) +You can set a [CI/CD template](../../../ci/examples/index.md#cicd-templates) as a required pipeline configuration for all projects on a GitLab instance. You can use a template from: @@ -233,13 +233,13 @@ use a template from: NOTE: When you use a configuration defined in an instance template repository, - nested [`include:`](../../../ci/yaml/README.md#include) keywords + nested [`include:`](../../../ci/yaml/index.md#include) keywords (including `include:file`, `include:local`, `include:remote`, and `include:template`) [do not work](https://gitlab.com/gitlab-org/gitlab/-/issues/35345). The project CI/CD configuration merges into the required pipeline configuration when a pipeline runs. The merged configuration is the same as if the required pipeline configuration -added the project configuration with the [`include` keyword](../../../ci/yaml/README.md#include). +added the project configuration with the [`include` keyword](../../../ci/yaml/index.md#include). To view a project's full merged configuration, [View the merged YAML](../../../ci/pipeline_editor/index.md#view-expanded-configuration) in the pipeline editor. @@ -280,6 +280,45 @@ To set the maximum file size: 1. Enter the maximum file size, in bytes. 1. Click **Save size limits**. +## Runner registration + +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22225) in GitLab 14.1. +> - [Deployed behind a feature flag](../../feature_flags.md), disabled by default. +> - Disabled on GitLab.com. +> - Not recommended for production use. +> - To use in GitLab self-managed instances, ask a GitLab administrator to enable it. **(FREE SELF)** + +GitLab administrators can adjust who is allowed to register runners, by showing and hiding areas of the UI. + +By default, all members of a project and group are able to register runners. + +To change this: + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. Go to **Settings > CI/CD**. +1. Expand the **Runner registration** section. +1. Select the desired options. +1. Click **Save changes**. + +When the registration sections are hidden in the UI, members of the project or group that need to register runners must contact the administrators. + +This feature is currently behind a feature flag. +To enable it: + +**In Omnibus installations:** + +1. Enter the Rails console: + + ```shell + sudo gitlab-rails console + ``` + +1. Flip the switch and enable the feature flag: + + ```ruby + Feature.enable(:runner_registration_control) + ``` + ## Troubleshooting ### 413 Request Entity Too Large diff --git a/doc/user/admin_area/settings/gitaly_timeouts.md b/doc/user/admin_area/settings/gitaly_timeouts.md index 6f488efee11..04887906c91 100644 --- a/doc/user/admin_area/settings/gitaly_timeouts.md +++ b/doc/user/admin_area/settings/gitaly_timeouts.md @@ -8,23 +8,20 @@ type: reference # Gitaly timeouts **(FREE SELF)** [Gitaly](../../../administration/gitaly/index.md) timeouts are configurable. The timeouts can be -configured to make sure that long running Gitaly calls don't needlessly take up resources. +configured to make sure that long-running Gitaly calls don't needlessly take up resources. To access Gitaly timeout settings: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. On the left sidebar, select **Settings > Preferences**. -1. Expand the **Gitaly** section. +1. Expand the **Gitaly timeouts** section. ## Available timeouts -The following timeouts can be modified: +The following timeouts are available. -- **Default Timeout Period**. This timeout is the default for most Gitaly calls. It should be shorter than the - worker timeout that can be configured for [Puma](https://docs.gitlab.com/omnibus/settings/puma.html#puma-settings). - Used to make sure that Gitaly calls made within a web request cannot exceed the entire request timeout. - Defaults to 55 seconds. - -- **Fast Timeout Period**. This is the timeout for very short Gitaly calls. Defaults to 10 seconds. -- **Medium Timeout Period**. This timeout should be between the default and the fast timeout. - Defaults to 30 seconds. +| Timeout | Default | Description | +|:--------|:-----------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Default | 55 seconds | Timeout for most Gitaly calls (not enforced for `git` `fetch` and `push` operations, or Sidekiq jobs). For example, checking if a repository exists on disk. Makes sure that Gitaly calls made within a web request cannot exceed the entire request timeout. It should be shorter than the worker timeout that can be configured for [Puma](https://docs.gitlab.com/omnibus/settings/puma.html#puma-settings). If a Gitaly call timeout exceeds the worker timeout, the remaining time from the worker timeout is used to avoid having to terminate the worker. | +| Fast | 10 seconds | Timeout for fast Gitaly operations used within requests, sometimes multiple times. For example, checking if a repository exists on disk. If fast operations exceed this threshold, there may be a problem with a storage shard. Failing fast can help maintain the stability of the GitLab instance. | +| Medium | 30 seconds | Timeout for Gitaly operations that should be fast (possibly within requests) but preferably not used multiple times within a request. For example, loading blobs. Timeout that should be set between Default and Fast. | diff --git a/doc/user/admin_area/settings/help_page.md b/doc/user/admin_area/settings/help_page.md index d7c96c295f6..d2f99a51ec3 100644 --- a/doc/user/admin_area/settings/help_page.md +++ b/doc/user/admin_area/settings/help_page.md @@ -5,36 +5,58 @@ info: To determine the technical writer assigned to the Stage/Group associated w type: howto --- -# Customizing the 'Help' and login page messages +# Customize the Help and sign-in page messages In large organizations, it is useful to have information about who to contact or where -to go for help. You can customize and display this information on the GitLab server's -`/help` page and on the GitLab login page. +to go for help. You can customize and display this information on the GitLab `/help` page and on +the GitLab sign-in page. -## Adding a help message to the help page +## Add a help message to the Help page -You can add a help message, which is shown on the GitLab `/help` page (e.g., -<https://gitlab.com/help>) in a new section at the top of the `/help` page: +You can add a help message, which is shown at the top of the GitLab `/help` page (for example, +<https://gitlab.com/help>): 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. In the left sidebar, select **Settings > Preferences**, then expand **Help page**. -1. Under **Help page text**, fill in the information you wish to display on `/help`. -1. Save your changes. You can now see the message on `/help`. +1. Under **Additional text to show on the Help page**, fill in the information you wish to display on `/help`. +1. Select **Save changes**. You can now see the message on `/help`. -## Adding a help message to the login page **(STARTER)** +NOTE: +By default, `/help` is visible to unauthenticated users. However, if the +[**Public** visibility level](visibility_and_access_controls.md#restricted-visibility-levels) +is restricted, `/help` is visible only to signed-in users. -You can add a help message, which is shown on the GitLab login page in a new section -titled `Need Help?`, located below the login page message: +## Add a help message to the sign-in page **(STARTER)** + +You can add a help message, which is shown on the GitLab sign-in page. The message appears in a new +section titled **Need Help?**, located below the sign-in page message: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. In the left sidebar, select **Settings > Preferences**, then expand **Help page**. -1. Under **Help text**, fill in the information you wish to display on the login page. +1. Under **Additional text to show on the sign-in page**, fill in the information you wish to + display on the sign-in page. +1. Select **Save changes**. You can now see the message on the sign-in page. + +## Hide marketing-related entries from the Help page + +GitLab marketing-related entries are occasionally shown on the Help page. To hide these entries: -  +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > Preferences**, then expand **Help page**. +1. Select the **Hide marketing-related entries from the Help page** checkbox. +1. Select **Save changes**. -1. Save your changes. +## Set a custom Support page URL - +You can specify a custom URL to which users are directed when they: + +- Select **Support** from the Help dropdown. +- Select **See our website for help** on the Help page. + +1. On the top bar, select **Menu >** **{admin}** **Admin**. +1. In the left sidebar, select **Settings > Preferences**, then expand **Help page**. +1. Enter the URL in the **Support page URL** field. +1. Select **Save changes**. <!-- ## Troubleshooting diff --git a/doc/user/admin_area/settings/img/enforce_terms.png b/doc/user/admin_area/settings/img/enforce_terms.png Binary files differindex 699e0e63ceb..de1a82275ab 100644 --- a/doc/user/admin_area/settings/img/enforce_terms.png +++ b/doc/user/admin_area/settings/img/enforce_terms.png diff --git a/doc/user/admin_area/settings/img/help_page_help_text_ex_v12_3.png b/doc/user/admin_area/settings/img/help_page_help_text_ex_v12_3.png Binary files differdeleted file mode 100644 index 973be2e8b6e..00000000000 --- a/doc/user/admin_area/settings/img/help_page_help_text_ex_v12_3.png +++ /dev/null diff --git a/doc/user/admin_area/settings/img/help_page_help_text_v12_3.png b/doc/user/admin_area/settings/img/help_page_help_text_v12_3.png Binary files differdeleted file mode 100644 index 8848ea55cf3..00000000000 --- a/doc/user/admin_area/settings/img/help_page_help_text_v12_3.png +++ /dev/null diff --git a/doc/user/admin_area/settings/index.md b/doc/user/admin_area/settings/index.md index 6a5af09358d..d21b6c36224 100644 --- a/doc/user/admin_area/settings/index.md +++ b/doc/user/admin_area/settings/index.md @@ -68,7 +68,7 @@ To access the default page for Admin Area settings: | 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 SELF)** | Set an instance-wide auto included [pipeline configuration](../../../ci/yaml/README.md). This pipeline configuration is run after the project's own configuration. | +| [Required pipeline configuration](continuous_integration.md#required-pipeline-configuration) **(PREMIUM SELF)** | Set an instance-wide auto included [pipeline configuration](../../../ci/yaml/index.md). This pipeline configuration is run after the project's own configuration. | | [Package Registry](continuous_integration.md#package-registry-configuration) | Settings related to the use and experience of using the GitLab Package Registry. Note there are [risks involved](../../packages/container_registry/index.md#use-with-external-container-registries) in enabling some of these settings. | ## Reporting @@ -86,7 +86,7 @@ To access the default page for Admin Area settings: | [Metrics - Grafana](../../../administration/monitoring/performance/grafana_configuration.md#integration-with-gitlab-ui) | Enable and configure Grafana. | | [Profiling - Performance bar](../../../administration/monitoring/performance/performance_bar.md#enable-the-performance-bar-via-the-admin-area) | Enable access to the Performance Bar for a given group. | | [Self monitoring](../../../administration/monitoring/gitlab_self_monitoring_project/index.md#creating-the-self-monitoring-project) | Enable or disable instance self monitoring. | -| [Usage statistics](usage_statistics.md) | Enable or disable version check and usage ping. | +| [Usage statistics](usage_statistics.md) | Enable or disable version check and Service Ping. | | [Pseudonymizer data collection](../../../administration/pseudonymizer.md) **(ULTIMATE)** | Enable or disable the Pseudonymizer data collection. | ## Network diff --git a/doc/user/admin_area/settings/sign_in_restrictions.md b/doc/user/admin_area/settings/sign_in_restrictions.md index ecd259a345c..333e9465c31 100644 --- a/doc/user/admin_area/settings/sign_in_restrictions.md +++ b/doc/user/admin_area/settings/sign_in_restrictions.md @@ -21,7 +21,7 @@ To access sign-in restriction settings: You can restrict the password authentication for web interface and Git over HTTP(S): -- **Web interface**: When this feature is disabled, the **Standard** sign-in tab is removed and an [external authentication provider](../../../administration/auth/README.md) must be used. +- **Web interface**: When this feature is disabled, the **Standard** sign-in tab is removed and an [external authentication provider](../../../administration/auth/index.md) must be used. - **Git over HTTP(S)**: When this feature is disabled, a [Personal Access Token](../../profile/personal_access_tokens.md) must be used to authenticate. ## Admin Mode diff --git a/doc/user/admin_area/settings/third_party_offers.md b/doc/user/admin_area/settings/third_party_offers.md index e7fa8b1dc40..6f7cb081315 100644 --- a/doc/user/admin_area/settings/third_party_offers.md +++ b/doc/user/admin_area/settings/third_party_offers.md @@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w type: reference --- -# Third party offers **(FREE SELF)** +# Third-party offers **(FREE SELF)** > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20379) in GitLab Free 11.1. @@ -16,8 +16,9 @@ for using [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/ To toggle the display of third-party offers: 1. On the top bar, select **Menu >** **{admin}** **Admin**. -1. In the left sidebar, select **Settings**, and expand **Third party offers**. -1. Select **Do not display offers from third parties within GitLab**. +1. On the left sidebar, select **Settings**, and expand **Third-party offers**. +1. Select **Do not display offers from third parties**. +1. Select **Save changes**. <!-- ## Troubleshooting diff --git a/doc/user/admin_area/settings/usage_statistics.md b/doc/user/admin_area/settings/usage_statistics.md index b5a7ce318ff..c12b720edd2 100644 --- a/doc/user/admin_area/settings/usage_statistics.md +++ b/doc/user/admin_area/settings/usage_statistics.md @@ -14,7 +14,7 @@ All statistics are opt-out. To enable or disable them: 1. On the top bar, select **Menu >** **{admin}** **Admin**. 1. In the left sidebar, select **Settings > Metrics and profiling**, and expand **Usage statistics**. -1. Enable or disable **Version check** and **Usage ping**. +1. Enable or disable **Version check** and **Service ping**. 1. Select **Save changes**. ## Network configuration @@ -67,14 +67,14 @@ sequenceDiagram Version Application->>GitLab instance: Response (PNG/SVG) ``` -## Usage Ping **(FREE SELF)** +## Service Ping **(FREE SELF)** -See [Usage Ping guide](../../../development/usage_ping/index.md). +See [Service Ping guide](../../../development/service_ping/index.md). ## Instance-level analytics availability -After usage ping is enabled, GitLab gathers data from other instances and -enables certain [instance-level analytics features](../analytics/index.md) that are dependent on usage ping. +After Service Ping is enabled, GitLab gathers data from other instances and +enables certain [instance-level analytics features](../analytics/index.md) that are dependent on Service Ping. <!-- ## Troubleshooting 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 752856371bf..4af33c133a4 100644 --- a/doc/user/admin_area/settings/visibility_and_access_controls.md +++ b/doc/user/admin_area/settings/visibility_and_access_controls.md @@ -97,7 +97,8 @@ 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). -1. Delete the project as described in the [Administering Projects page](../../admin_area/#administering-projects). +1. Delete the project as described in the + [Administering Projects page](../../admin_area/#administering-projects). ## Default project visibility @@ -106,7 +107,8 @@ To set the default visibility levels for new projects: 1. Select the desired default project visibility. 1. Click **Save changes**. -For more details on project visibility, see [Public access](../../../public_access/public_access.md). +For more details on project visibility, see +[Project visibility](../../../public_access/public_access.md). ## Default snippet visibility @@ -115,7 +117,8 @@ To set the default visibility levels for new snippets: 1. Select the desired default snippet visibility. 1. Click **Save changes**. -For more details on snippet visibility, see [Public access](../../../public_access/public_access.md). +For more details on snippet visibility, see +[Project visibility](../../../public_access/public_access.md). ## Default group visibility @@ -124,7 +127,8 @@ To set the default visibility levels for new groups: 1. Select the desired default group visibility. 1. Click **Save changes**. -For more details on group visibility, see [Public access](../../../public_access/public_access.md). +For more details on group visibility, see +[Group visibility](../../group/index.md#group-visibility). ## Restricted visibility levels @@ -133,7 +137,8 @@ To set the restricted visibility levels for projects, snippets, and selected pag 1. Select the desired visibility levels to restrict. 1. Select **Save changes**. -For more details on project visibility, see [Public access](../../../public_access/public_access.md). +For more details on project visibility, see +[Project visibility](../../../public_access/public_access.md). ## Import sources |
