diff options
Diffstat (limited to 'doc')
59 files changed, 305 insertions, 193 deletions
diff --git a/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md b/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md index 0d03b481881..15276d364a0 100644 --- a/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md +++ b/doc/administration/auth/how_to_configure_ldap_gitlab_ce/index.md @@ -14,7 +14,7 @@ Managing a large number of users in GitLab can become a burden for system admini In this guide we will focus on configuring GitLab with Active Directory. [Active Directory](https://en.wikipedia.org/wiki/Active_Directory) is a popular LDAP compatible directory service provided by Microsoft, included in all modern Windows Server operating systems. -GitLab has supported LDAP integration since [version 2.2](https://about.gitlab.com/2012/02/22/gitlab-version-2-2/). With GitLab LDAP [group syncing](#group-syncing-ee) being added to GitLab Enterprise Edition in [version 6.0](https://about.gitlab.com/2013/08/20/gitlab-6-dot-0-released/). LDAP integration has become one of the most popular features in GitLab. +GitLab has supported LDAP integration since [version 2.2](https://about.gitlab.com/2012/02/22/gitlab-version-2-2/). With GitLab LDAP [group syncing](https://docs.gitlab.com/ee/administration/auth/how_to_configure_ldap_gitlab_ee/index.html#group-sync) being added to GitLab Enterprise Edition in [version 6.0](https://about.gitlab.com/2013/08/20/gitlab-6-dot-0-released/). LDAP integration has become one of the most popular features in GitLab. ## Getting started @@ -111,7 +111,7 @@ The initial configuration of LDAP in GitLab requires changes to the `gitlab.rb` The two Active Directory specific values are `active_directory: true` and `uid: 'sAMAccountName'`. `sAMAccountName` is an attribute returned by Active Directory used for GitLab usernames. See the example output from `ldapsearch` for a full list of attributes a "person" object (user) has in **AD** - [`ldapsearch` example](#using-ldapsearch-unix) -> Both group_base and admin_group configuration options are only available in GitLab Enterprise Edition. See [GitLab EE - LDAP Features](#gitlab-enterprise-edition---ldap-features) +> Both group_base and admin_group configuration options are only available in GitLab Enterprise Edition. See [GitLab EE - LDAP Features](https://docs.gitlab.com/ee/administration/auth/how_to_configure_ldap_gitlab_ee/index.html#gitlab-enterprise-edition---ldap-features) ### Example `gitlab.rb` LDAP diff --git a/doc/administration/auth/ldap.md b/doc/administration/auth/ldap.md index 01cf7489c09..440c2b1285a 100644 --- a/doc/administration/auth/ldap.md +++ b/doc/administration/auth/ldap.md @@ -81,6 +81,9 @@ library. `tls` corresponds to StartTLS, not to be confused with regular TLS. Normally, if you specify `ssl` it will be on port 636, while `tls` (StartTLS) would be on port 389. `plain` also operates on port 389. +NOTE: **Note:** +LDAP users must have an email address set, regardless of whether it is used to log in. + **Omnibus configuration** ```ruby diff --git a/doc/administration/auth/okta.md b/doc/administration/auth/okta.md index 3136923fa96..638405126a5 100644 --- a/doc/administration/auth/okta.md +++ b/doc/administration/auth/okta.md @@ -1,6 +1,6 @@ # Okta SSO provider -Okta is a [Single Sign-on provider][okta-sso] that can be used to authenticate +Okta is a [Single Sign-on provider](https://www.okta.com/products/single-sign-on/) that can be used to authenticate with GitLab. The following documentation enables Okta as a SAML provider. @@ -140,7 +140,7 @@ Now that the Okta app is configured, it's time to enable it in GitLab. } ``` -1. [Reconfigure][reconf] or [restart] GitLab for Omnibus and installations +1. [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart](../restart_gitlab.md#installations-from-source) GitLab for Omnibus and installations from source respectively for the changes to take effect. You might want to try this out on an incognito browser window. @@ -150,10 +150,5 @@ You might want to try this out on an incognito browser window. >**Note:** Make sure the groups exist and are assigned to the Okta app. -You can take a look of the [SAML documentation][saml] on external groups since +You can take a look of the [SAML documentation](../../integration/saml.md#marking-users-as-external-based-on-saml-groups) on external groups since it works the same. - -[okta-sso]: https://www.okta.com/products/single-sign-on/ -[saml]: ../../integration/saml.md#external-groups -[reconf]: ../restart_gitlab.md#omnibus-gitlab-reconfigure -[restart]: ../restart_gitlab.md#installations-from-source diff --git a/doc/administration/compliance.md b/doc/administration/compliance.md index 0414b3ec12e..72cb57fb36c 100644 --- a/doc/administration/compliance.md +++ b/doc/administration/compliance.md @@ -6,12 +6,12 @@ GitLab’s [security features](../security/README.md) may also help you meet rel |Feature |GitLab tier |GitLab.com | | ---------| :--------: | :-------: | -|**[Restrict SSH Keys](../README.html#administrator-documentation)**<br>Control the technology and key length of SSH keys used to access GitLab|Core+|| -|**[Granular user roles and flexible permissions](../user/permissions.html)**<br>Manage access and permissions with five different user roles and settings for external users. Set permissions according to people's role, rather than either read or write access to a repository. Don't share the source code with people that only need access to the issue tracker.|Core+|✓| -|**[Enforce TOS acceptance](../user/admin_area/settings/terms.html)**<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.html)**<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+|| +|**[Restrict SSH Keys](../security/ssh_keys_restrictions.md)**<br>Control the technology and key length of SSH keys used to access GitLab|Core+|| +|**[Granular user roles and flexible permissions](../user/permissions.md)**<br>Manage access and permissions with five different user roles and settings for external users. Set permissions according to people's role, rather than either read or write access to a repository. Don't share the source code with people that only need access to the issue tracker.|Core+|✓| +|**[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](../workflow/groups.html#lock-project-membership-to-members-of-this-group)**<br>Group owners can prevent new members from being added to projects within a group.|Starter+|✓| +|**[Lock project membership to group](https://docs.gitlab.com/ee/user/group/index.html#member-lock-starter)**<br>Group owners can prevent new members from being added to projects within a group.|Starter+|✓| |**[LDAP group sync](https://docs.gitlab.com/ee/administration/auth/ldap-ee.html#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](https://docs.gitlab.com/ee/administration/auth/ldap-ee.html#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](https://docs.gitlab.com/ee/administration/audit_events.html)**<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+|| diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md index 0795d3dad40..2d4b5c65c46 100644 --- a/doc/administration/gitaly/index.md +++ b/doc/administration/gitaly/index.md @@ -45,9 +45,13 @@ installations that are larger than a single machine. Most installations will be better served with the default configuration used by Omnibus and the GitLab source installation guide. -Starting with GitLab 11.4, Gitaly is a replacement for NFS except -when the [Elastic Search indexer](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer) -is used. +Starting with GitLab 11.4, Gitaly is able to serve all Git requests without +needed a shared NFS mount for Git repository data. +Between 11.4 and 11.8 the exception was the +[Elastic Search indexer](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). +But since 11.8 the indexer uses Gitaly for data access as well. NFS can still +be leveraged for redudancy on block level of the Git data. But only has to +be mounted on the Gitaly server. ### Network architecture @@ -62,14 +66,16 @@ is used. - Gitaly addresses must be specified in such a way that they resolve correctly for ALL Gitaly clients - Gitaly clients are: unicorn, sidekiq, gitlab-workhorse, - gitlab-shell, and Gitaly itself + gitlab-shell, Elasticsearch Indexer, and Gitaly itself - special case: a Gitaly server must be able to make RPC calls **to itself** via its own (Gitaly address, Gitaly token) pair as specified in `gitlab-rails/config/gitlab.yml` - Gitaly servers must not be exposed to the public internet -Gitaly network traffic is unencrypted so you should use a firewall to -restrict access to your Gitaly server. +Gitaly network traffic is unencrypted by default, but supports +[TLS](#tls-support). Authentication is done through a static token. For +security in depth, its recommended to use a firewall to restrict access +to your Gitaly server. Below we describe how to configure a Gitaly server at address `gitaly.internal:8075` with secret token `abc123secret`. We assume @@ -194,17 +200,16 @@ server from reaching the Gitaly server then all Gitaly requests will fail. We assume that your Gitaly server can be reached at -`gitaly.internal:8075` from your GitLab server, and that your GitLab -NFS shares are mounted at `/mnt/gitlab/default` and -`/mnt/gitlab/storage1` respectively. +`gitaly.internal:8075` from your GitLab server, and that Gitaly can read and +write to `/mnt/gitlab/default` and `/mnt/gitlab/storage1` respectively. Omnibus installations: ```ruby # /etc/gitlab/gitlab.rb git_data_dirs({ - 'default' => { 'path' => '/mnt/gitlab/default', 'gitaly_address' => 'tcp://gitaly.internal:8075' }, - 'storage1' => { 'path' => '/mnt/gitlab/storage1', 'gitaly_address' => 'tcp://gitaly.internal:8075' }, + 'default' => { 'gitaly_address' => 'tcp://gitaly.internal:8075' }, + 'storage1' => { 'gitaly_address' => 'tcp://gitaly.internal:8075' }, }) gitlab_rails['gitaly_token'] = 'abc123secret' @@ -218,10 +223,8 @@ gitlab: repositories: storages: default: - path: /mnt/gitlab/default/repositories gitaly_address: tcp://gitaly.internal:8075 storage1: - path: /mnt/gitlab/storage1/repositories gitaly_address: tcp://gitaly.internal:8075 gitaly: @@ -236,7 +239,7 @@ repository from your GitLab server over HTTP. ## TLS support -> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22602) in GitLab 11.7. +> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22602) in GitLab 11.8. Gitaly supports TLS credentials for GRPC authentication. To be able to communicate with a Gitaly instance that listens for secure connections you will need to use `tls://` url diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md index 74b0e2c8184..78ebf8a083b 100644 --- a/doc/administration/high_availability/nfs.md +++ b/doc/administration/high_availability/nfs.md @@ -37,6 +37,28 @@ options: circumstances it could lead to data loss if a failure occurs before data has synced. +### Improving NFS performance with GitLab + +If you are using NFS to share Git data, we recommend that you enable a +number of feature flags that will allow GitLab application processes to +access Git data directly instead of going through the [Gitaly +service](../gitaly/index.md). Depending on your workload and disk +performance, these flags may help improve performance. See [the +issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/57317) for more +details. + +To do this, run the Rake task: + +```sh +gitlab-rake gitlab:features:enable_rugged +``` + +If you need to undo this setting for some reason, run: + +```sh +gitlab-rake gitlab:features:disable_rugged +``` + ### Known issues On some customer systems, we have seen NFS clients slow precipitously due to diff --git a/doc/administration/index.md b/doc/administration/index.md index 6e08d4633cd..b723edfc78f 100644 --- a/doc/administration/index.md +++ b/doc/administration/index.md @@ -130,7 +130,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 traces](job_traces.md): Information about the job traces (logs). - [Register Shared and specific Runners](../ci/runners/README.md#registering-a-shared-runner): Learn how to register and configure Shared and specific Runners to your own instance. -- [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. +- [Shared Runners pipelines quota](https://docs.gitlab.com/ee/user/admin_area/settings/continuous_integration.html#shared-runners-pipeline-minutes-quota-starter-only): 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. ## Git configuration options diff --git a/doc/administration/job_artifacts.md b/doc/administration/job_artifacts.md index 25ae535d1ec..8522d046a92 100644 --- a/doc/administration/job_artifacts.md +++ b/doc/administration/job_artifacts.md @@ -274,7 +274,7 @@ you can flip the feature flag from a Rails console. ## Set the maximum file size of the artifacts Provided the 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). +artifacts through the [Admin area settings](../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size-core-only). ## Storage statistics diff --git a/doc/administration/monitoring/prometheus/index.md b/doc/administration/monitoring/prometheus/index.md index 8f65cd6418c..20d7ef9bb74 100644 --- a/doc/administration/monitoring/prometheus/index.md +++ b/doc/administration/monitoring/prometheus/index.md @@ -17,7 +17,7 @@ access to high quality time-series monitoring of GitLab services. ## Overview Prometheus works by periodically connecting to data sources and collecting their -performance metrics via the [various exporters](#prometheus-exporters). To view +performance metrics via the [various exporters](#bundled-software-metrics). To view and work with the monitoring data, you can either [connect directly to Prometheus](#viewing-performance-metrics) or utilize a dashboard tool like [Grafana]. diff --git a/doc/administration/operations/sidekiq_memory_killer.md b/doc/administration/operations/sidekiq_memory_killer.md index cbffd883774..8eac42f2fe2 100644 --- a/doc/administration/operations/sidekiq_memory_killer.md +++ b/doc/administration/operations/sidekiq_memory_killer.md @@ -17,6 +17,11 @@ With the default settings, the MemoryKiller will cause a Sidekiq restart no more often than once every 15 minutes, with the restart causing about one minute of delay for incoming background jobs. +Some background jobs rely on long-running external processes. To ensure these +are cleanly terminated when Sidekiq is restarted, each Sidekiq process should be +run as a process group leader (e.g., using `chpst -P`). If using Omnibus or the +`bin/background_jobs` script with `runit` installed, this is handled for you. + ## Configuring the MemoryKiller The MemoryKiller is controlled using environment variables. diff --git a/doc/administration/raketasks/uploads/migrate.md b/doc/administration/raketasks/uploads/migrate.md index b5c40478ea5..fd8ea8d3162 100644 --- a/doc/administration/raketasks/uploads/migrate.md +++ b/doc/administration/raketasks/uploads/migrate.md @@ -2,7 +2,7 @@ ## Migrate to Object Storage -After [configuring the object storage](../../uploads.md#using-object-storage) for GitLab's uploads, you may use this task to migrate existing uploads from the local storage to the remote storage. +After [configuring the object storage](../../uploads.md#using-object-storage-core-only) for GitLab's uploads, you may use this task to migrate existing uploads from the local storage to the remote storage. >**Note:** All of the processing will be done in a background worker and requires **no downtime**. diff --git a/doc/administration/repository_checks.md b/doc/administration/repository_checks.md index 8b725e50f58..7cf8f20a9dc 100644 --- a/doc/administration/repository_checks.md +++ b/doc/administration/repository_checks.md @@ -31,7 +31,7 @@ panel. If the repository check fails for some repository you should look up the error in `repocheck.log`: -- in the [admin panel](logs.md#repocheck-log) +- in the [admin panel](logs.md#repochecklog) - or on disk, see: - `/var/log/gitlab/gitlab-rails` for Omnibus installations - `/home/git/gitlab/log` for installations from source diff --git a/doc/api/README.md b/doc/api/README.md index 48d9ad8f30d..7ec7955c596 100644 --- a/doc/api/README.md +++ b/doc/api/README.md @@ -274,7 +274,7 @@ personal access tokens, and to using the [Sudo](#sudo) feature, since the user's password/token may not be known or may change over time. For more information, refer to the -[users API](users.md#retrieve-user-impersonation-tokens) docs. +[users API](users.md#create-an-impersonation-token) docs. Impersonation tokens are used exactly like regular personal access tokens, and can be passed in either the `private_token` parameter or the `Private-Token` header. diff --git a/doc/articles/index.md b/doc/articles/index.md index 87ee17bb6de..162db11d6ac 100644 --- a/doc/articles/index.md +++ b/doc/articles/index.md @@ -4,8 +4,8 @@ comments: false # Technical articles list (deprecated) -[Technical articles](../development/documentation/index.md#technical-articles) are -topic-related documentation, written with an user-friendly approach and language, aiming +Technical articles are +topic-related documentation, written with a user-friendly approach and language, aiming to provide the community with guidance on specific processes to achieve certain objectives. The list of technical articles was [deprecated](https://gitlab.com/gitlab-org/gitlab-ce/issues/41138) in favor of having them linked from their topic-related documentation: diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md index 6fe352df48a..08db89124de 100644 --- a/doc/ci/variables/README.md +++ b/doc/ci/variables/README.md @@ -79,19 +79,23 @@ future GitLab releases.** | **CI_JOB_STAGE** | 9.0 | 0.5 | The name of the stage as defined in `.gitlab-ci.yml` | | **CI_JOB_TOKEN** | 9.0 | 1.2 | Token used for authenticating with the [GitLab Container Registry][registry] and downloading [dependent repositories][dependent-repositories] | | **CI_JOB_URL** | 11.1 | 0.5 | Job details URL | -| **CI_MERGE_REQUEST_ID** | 11.6 | all | The ID of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) | -| **CI_MERGE_REQUEST_IID** | 11.6 | all | The IID of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) | -| **CI_MERGE_REQUEST_PROJECT_ID** | 11.6 | all | The ID of the project of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) | -| **CI_MERGE_REQUEST_PROJECT_PATH** | 11.6 | all | The path of the project of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) (e.g. `namespace/awesome-project`) | -| **CI_MERGE_REQUEST_PROJECT_URL** | 11.6 | all | The URL of the project of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) (e.g. `http://192.168.10.15:3000/namespace/awesome-project`) | -| **CI_MERGE_REQUEST_REF_PATH** | 11.6 | all | The ref path of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md). (e.g. `refs/merge-requests/1/head`) | -| **CI_MERGE_REQUEST_SOURCE_BRANCH_NAME** | 11.6 | all | The source branch name of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) | -| **CI_MERGE_REQUEST_SOURCE_BRANCH_SHA** | 11.9 | all | The HEAD sha of the source branch of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) | -| **CI_MERGE_REQUEST_SOURCE_PROJECT_ID** | 11.6 | all | The ID of the source project of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) | -| **CI_MERGE_REQUEST_SOURCE_PROJECT_PATH** | 11.6 | all | The path of the source project of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) | -| **CI_MERGE_REQUEST_SOURCE_PROJECT_URL** | 11.6 | all | The URL of the source project of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) | -| **CI_MERGE_REQUEST_TARGET_BRANCH_NAME** | 11.6 | all | The target branch name of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) | -| **CI_MERGE_REQUEST_TARGET_BRANCH_SHA** | 11.9 | all | The HEAD sha of the target branch of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) | +| **CI_MERGE_REQUEST_ID** | 11.6 | all | The ID of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) | +| **CI_MERGE_REQUEST_IID** | 11.6 | all | The IID of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) | +| **CI_MERGE_REQUEST_PROJECT_ID** | 11.6 | all | The ID of the project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) | +| **CI_MERGE_REQUEST_PROJECT_PATH** | 11.6 | all | The path of the project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) (e.g. `namespace/awesome-project`) | +| **CI_MERGE_REQUEST_PROJECT_URL** | 11.6 | all | The URL of the project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) (e.g. `http://192.168.10.15:3000/namespace/awesome-project`) | +| **CI_MERGE_REQUEST_REF_PATH** | 11.6 | all | The ref path of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). (e.g. `refs/merge-requests/1/head`) | +| **CI_MERGE_REQUEST_SOURCE_BRANCH_NAME** | 11.6 | all | The source branch name of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) | +| **CI_MERGE_REQUEST_SOURCE_BRANCH_SHA** | 11.9 | all | The HEAD sha of the source branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) | +| **CI_MERGE_REQUEST_SOURCE_PROJECT_ID** | 11.6 | all | The ID of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) | +| **CI_MERGE_REQUEST_SOURCE_PROJECT_PATH** | 11.6 | all | The path of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) | +| **CI_MERGE_REQUEST_SOURCE_PROJECT_URL** | 11.6 | all | The URL of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) | +| **CI_MERGE_REQUEST_TARGET_BRANCH_NAME** | 11.6 | all | The target branch name of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) | +| **CI_MERGE_REQUEST_TARGET_BRANCH_SHA** | 11.9 | all | The HEAD sha of the target branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) | +| **CI_MERGE_REQUEST_TITLE** | 11.9 | all | The title of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) | +| **CI_MERGE_REQUEST_ASSIGNEES** | 11.9 | all | Comma-separated usernames of the assignees of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). **Comming soon**: [Multitle assignees for merge requests](https://gitlab.com/gitlab-org/gitlab-ee/issues/2004) | +| **CI_MERGE_REQUEST_MILESTONE** | 11.9 | all | The milestone title of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) | +| **CI_MERGE_REQUEST_LABELS** | 11.9 | all | Comma-separated label names of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) | | **CI_NODE_INDEX** | 11.5 | all | Index of the job in the job set. If the job is not parallelized, this variable is not set. | | **CI_NODE_TOTAL** | 11.5 | all | Total number of instances of this job running in parallel. If the job is not parallelized, this variable is set to `1`. | | **CI_API_V4_URL** | 11.7 | all | The GitLab API v4 root URL | diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 455ab900764..4db4b71ecaf 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -1594,6 +1594,9 @@ You can only use files that are currently tracked by Git on the same branch your configuration file is on. In other words, when using a `include:local`, make sure that both `.gitlab-ci.yml` and the local file are on the same branch. +All [nested includes](#nested-includes) will be executed in the scope of the same project, +so it is possible to use local, project, remote or template includes. + NOTE: **Note:** Including local files through Git submodules paths is not supported. @@ -1606,7 +1609,7 @@ include: ### `include:file` -> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/53903) in GitLab 11.7. +> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/53903) in GitLab 11.9. To include files from another private project under the same GitLab instance, use `include:file`. This file is referenced using full paths relative to the @@ -1635,6 +1638,10 @@ include: file: '/templates/.gitlab-ci-template.yml' ``` +All nested includes will be executed in the scope of the target project, +so it is possible to used local (relative to target project), project, remote +or template includes. + ### `include:template` > [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/53445) in GitLab 11.7. @@ -1650,6 +1657,9 @@ include: - template: Auto-DevOps.gitlab-ci.yml ``` +All nested includes will be executed only with the permission of the user, +so it is possible to use project, remote or template includes. + ### `include:remote` `include:remote` can be used to include a file from a different location, @@ -1662,10 +1672,16 @@ include: - remote: 'https://gitlab.com/awesome-project/raw/master/.gitlab-ci-template.yml' ``` -NOTE: **Note for GitLab admins:** -In order to include files from another repository inside your local network, -you may need to enable the **Allow requests to the local network from hooks and services** checkbox -located in the **Admin area > Settings > Network > Outbound requests** section. +All nested includes will be executed without context as public user, so only another remote, +or public project, or template is allowed. + +### Nested includes + +> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/53903) in GitLab 11.7. + +Nested includes allow you to compose a set of includes. +A total of 50 includes is allowed. +Duplicate includes are considered a configuration error. ### `include` examples @@ -1834,6 +1850,51 @@ In this case, if `install_dependencies` and `deploy` were not repeated in `.gitlab-ci.yml`, they would not be part of the script for the `production` job in the combined CI configuration. +#### Using nested includes + +The examples below show how includes can be nested from different sources +using a combination of different methods. + +In this example, `.gitlab-ci.yml` includes local the file `/.gitlab-ci/another-config.yml`: + +```yaml +includes: + - local: /.gitlab-ci/another-config.yml +``` + +The `/.gitlab-ci/another-config.yml` includes a template and the `/templates/docker-workflow.yml` file +from another project: + +```yaml +includes: + - template: Bash.gitlab-ci.yml + - project: /group/my-project + file: /templates/docker-workflow.yml +``` + +The `/templates/docker-workflow.yml` present in `/group/my-project` includes two local files +of the `/group/my-project`: + +```yaml +includes: + - local: : /templates/docker-build.yml + - local: : /templates/docker-testing.yml +``` + +Our `/templates/docker-build.yml` present in `/group/my-project` adds a `docker-build` job: + +```yaml +docker-build: + script: docker build -t my-image . +``` + +Our second `/templates/docker-test.yml` present in `/group/my-project` adds a `docker-test` job: + +```yaml +docker-test: + script: docker run my-image /run/tests.sh +``` + ## `extends` > Introduced in GitLab 11.3. diff --git a/doc/development/architecture.md b/doc/development/architecture.md index e22552fd3a3..ae880e3deb6 100644 --- a/doc/development/architecture.md +++ b/doc/development/architecture.md @@ -65,14 +65,14 @@ Gitaly is a service designed by GitLab to remove our need for NFS for Git storag - Omnibus configuration options - Layer: Monitoring -GitLab Monitor is a process disigned in house that allows us to export metrics about GitLab application internals to prometheus. You can read more [in the project's readme](https://gitlab.com/gitlab-org/gitlab-monitor) +GitLab Monitor is a process designed in house that allows us to export metrics about GitLab application internals to prometheus. You can read more [in the project's readme](https://gitlab.com/gitlab-org/gitlab-monitor) ### gitlab-workhorse - Omnibus configuration options - Layer: Core Service (Processor) -[GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse) is a program designed at GitLab to help alieviate pressure from unicorn. You can read more about the [historical reasons for developing](https://about.gitlab.com/2016/04/12/a-brief-history-of-gitlab-workhorse/). It's designed to act as a smart reverse proxy to help speed up GitLab as a whole. +[GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse) is a program designed at GitLab to help alleviate pressure from unicorn. You can read more about the [historical reasons for developing](https://about.gitlab.com/2016/04/12/a-brief-history-of-gitlab-workhorse/). It's designed to act as a smart reverse proxy to help speed up GitLab as a whole. ### logrotate diff --git a/doc/development/changelog.md b/doc/development/changelog.md index cd0a1f46d27..6efed36edf0 100644 --- a/doc/development/changelog.md +++ b/doc/development/changelog.md @@ -135,21 +135,13 @@ If you're working on the GitLab EE repository, the entry will be added to | Argument | Shorthand | Purpose | | ----------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------- | -| [`--amend`] | | Amend the previous commit | -| [`--force`] | `-f` | Overwrite an existing entry | -| [`--merge-request`] | `-m` | Set merge request ID | -| [`--dry-run`] | `-n` | Don't actually write anything, just print | -| [`--git-username`] | `-u` | Use Git user.name configuration as the author | -| [`--type`] | `-t` | The category of the change, valid options are: `added`, `fixed`, `changed`, `deprecated`, `removed`, `security`, `performance`, `other` | -| [`--help`] | `-h` | Print help message | - -[`--amend`]: #-amend -[`--force`]: #-force-or-f -[`--merge-request`]: #-merge-request-or-m -[`--dry-run`]: #-dry-run-or-n -[`--git-username`]: #-git-username-or-u -[`--type`]: #-type-or-t -[`--help`]: #-help +| [`--amend`](#--amend) | | Amend the previous commit | +| [`--force`](#--force-or--f) | `-f` | Overwrite an existing entry | +| [`--merge-request`](#--merge-request-or--m) | `-m` | Set merge request ID | +| [`--dry-run`](#--dry-run-or--n) | `-n` | Don't actually write anything, just print | +| [`--git-username`](#--git-username-or--u) | `-u` | Use Git user.name configuration as the author | +| [`--type`](#--type-or--t) | `-t` | The category of the change, valid options are: `added`, `fixed`, `changed`, `deprecated`, `removed`, `security`, `performance`, `other` | +| `--help` | `-h` | Print help message | ##### `--amend` diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md index 4e766f37871..8b14c3b20ea 100644 --- a/doc/development/contributing/merge_request_workflow.md +++ b/doc/development/contributing/merge_request_workflow.md @@ -179,7 +179,7 @@ the feature you contribute through all of these steps. 1. Added to [the website](https://gitlab.com/gitlab-com/www-gitlab-com/), if relevant 1. Community questions answered 1. Answers to questions radiated (in docs/wiki/support etc.) -1. [Black-box tests/end-to-end tests](../testing_guide/testing_levels.md#black-box-tests-or-end-to-end-tests) added if required. Please contact [the quality team](https://about.gitlab.com/handbook/engineering/quality/#teams) with any questions +1. [Black-box tests/end-to-end tests](../testing_guide/testing_levels.md#black-box-tests-at-the-system-level-aka-end-to-end-tests) added if required. Please contact [the quality team](https://about.gitlab.com/handbook/engineering/quality/#teams) with any questions If you add a dependency in GitLab (such as an operating system package) please consider updating the following and note the applicability of each in your diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md index 652fe3ea711..a4da34a50ce 100644 --- a/doc/development/documentation/index.md +++ b/doc/development/documentation/index.md @@ -511,10 +511,10 @@ Currently, the following tests are in place: 1. `docs lint`: Check that all internal (relative) links work correctly and that all cURL examples in API docs use the full switches. It's recommended - to [check locally](#previewing-locally) before pushing to GitLab by executing the command + to [check locally](#previewing-the-changes-live) before pushing to GitLab by executing the command `bundle exec nanoc check internal_links` on your local [`gitlab-docs`](https://gitlab.com/gitlab-com/gitlab-docs) directory. -1. [`ee_compat_check`](../automatic_ce_ee_merge.md#avoiding-ce-gt-ee-merge-conflicts-beforehand) (runs on CE only): +1. [`ee_compat_check`](../automatic_ce_ee_merge.md#avoiding-ce-ee-merge-conflicts-beforehand) (runs on CE only): When you submit a merge request to GitLab Community Edition (CE), there is this additional job that runs against Enterprise Edition (EE) and checks if your changes can apply cleanly to the EE codebase. diff --git a/doc/development/documentation/site_architecture/global_nav.md b/doc/development/documentation/site_architecture/global_nav.md index 0aa3c41a225..f2f4f5f0e1c 100644 --- a/doc/development/documentation/site_architecture/global_nav.md +++ b/doc/development/documentation/site_architecture/global_nav.md @@ -62,7 +62,7 @@ the consent of one of the technical writers. The global nav is built from two files: - [Data](#data-file) -- [Layout](#layout-file) +- [Layout](#layout-file-logic) The data file feeds the layout with the links to the docs. The layout organizes the data among the nav in containers properly [styled](#css-classes). diff --git a/doc/development/documentation/styleguide.md b/doc/development/documentation/styleguide.md index cd38721e3ab..0c51d3832aa 100644 --- a/doc/development/documentation/styleguide.md +++ b/doc/development/documentation/styleguide.md @@ -36,7 +36,7 @@ gem will support all [GFM markup](../../user/markdown.md) in the future. For now use regular markdown markup, following the rules on this style guide. For a complete Kramdown reference, check the [GitLab Markdown Kramdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/). Use Kramdown markup wisely: do not overuse its specific markup (e.g., `{:.class}`) as it will not render properly in -[`/help`](#gitlab-help). +[`/help`](index.md#gitlab-help). ## Content @@ -630,7 +630,7 @@ In this case: - The code blocks are indented one or more spaces under the list item to render correctly. - Different highlighting languages are used for each config in the code block. -- The [references](#references) guide is used for reconfigure/restart. +- The [GitLab Restart](#gitlab-restart) section is used to explain a required restart/reconfigure of GitLab. ## API diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md index 17da4c51033..41a64044c68 100644 --- a/doc/development/ee_features.md +++ b/doc/development/ee_features.md @@ -161,7 +161,7 @@ still having access the class's implementation with `super`. There are a few gotchas with it: -- you should always [`extend ::Gitlab::Utils::Override`] and use `override` to +- you should always [`extend ::Gitlab::Utils::Override`](utilities.md#overridehttpsgitlabcomgitlab-orggitlab-ceblobmasterlibgitlabutilsoverriderb) and use `override` to guard the "overrider" method to ensure that if the method gets renamed in CE, the EE override won't be silently forgotten. - when the "overrider" would add a line in the middle of the CE @@ -273,8 +273,6 @@ module EE end ``` -[`extend ::Gitlab::Utils::Override`]: utilities.md#override - ##### Overriding CE class methods The same applies to class methods, except we want to use @@ -977,7 +975,7 @@ if (renderIfEE) { To separate EE-specific styles in SCSS files, if a component you're adding styles for is limited to only EE, it is better to have a separate SCSS file in appropriate directory within `app/assets/stylesheets`. -See [backporting changes](#backporting-changes) for instructions on how to merge changes safely. +See [backporting changes](#backporting-changes-from-EE-to-CE) for instructions on how to merge changes safely. In some cases, this is not entirely possible or creating dedicated SCSS file is an overkill, e.g. a text style of some component is different for EE. In such cases, diff --git a/doc/development/fe_guide/architecture.md b/doc/development/fe_guide/architecture.md index aebb22caa15..c67389b169e 100644 --- a/doc/development/fe_guide/architecture.md +++ b/doc/development/fe_guide/architecture.md @@ -11,12 +11,9 @@ Architectural decisions should be accessible to everyone, so please document them in the relevant Merge Request discussion or by updating our documentation when appropriate. -You can find the Frontend Architecture experts on the [team page][team-page]. +You can find the Frontend Architecture experts on the [team page](https://about.gitlab.com/team). ## Examples You can find documentation about the desired architecture for a new feature -built with Vue.js [here][vue-section]. - -[team-page]: https://about.gitlab.com/team -[vue-section]: vue.md#frontend.html#how-to-build-a-new-feature-with-vue-js +built with Vue.js [here](vue.md). diff --git a/doc/development/fe_guide/vue.md b/doc/development/fe_guide/vue.md index 3cd70bd63fa..435fdf39fb4 100644 --- a/doc/development/fe_guide/vue.md +++ b/doc/development/fe_guide/vue.md @@ -122,7 +122,7 @@ Check this [page](vuex.md) for more details. ## Style guide -Please refer to the Vue section of our [style guide](style_guide_js.md#vue-js) +Please refer to the Vue section of our [style guide](style_guide_js.md#vuejs) for best practices while writing your Vue components and templates. ## Testing Vue Components @@ -132,7 +132,7 @@ Each Vue component has a unique output. This output is always present in the ren Although we can test each method of a Vue component individually, our goal must be to test the output of the render/template function, which represents the state at all times. -Make use of the [axios mock adapter](axios.md#mock-axios-response-on-tests) to mock data returned. +Make use of the [axios mock adapter](axios.md#mock-axios-response-in-tests) to mock data returned. Here's how we would test the Todo App above: diff --git a/doc/development/gitaly.md b/doc/development/gitaly.md index d5fc403bf8b..b1785e6f803 100644 --- a/doc/development/gitaly.md +++ b/doc/development/gitaly.md @@ -5,8 +5,9 @@ Workhorse and GitLab-Shell. ## Developing new Git features -Starting with GitLab 10.8, all new Git features should be developed in -Gitaly. +To read or write Git data, a request has to be made to Gitaly. This means that +if you're developing a new feature where you need data that's not yet available +in `lib/gitlab/git` changes have to be made to Gitaly. > This is a new process that is not clearly defined yet. If you want to contribute a Git feature and you're getting stuck, reach out to the @@ -56,6 +57,44 @@ If your test-suite is failing with Gitaly issues, as a first step, try running: rm -rf tmp/tests/gitaly ``` +## Legacy Rugged code + +While Gitaly can handle all Git access, many of GitLab customers still +run Gitaly atop NFS. The legacy Rugged implementation for Git calls may +be faster than the Gitaly RPC due to N+1 Gitaly calls and other +reasons. See [the +issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/57317) for more +details. + +Until GitLab has eliminated most of these inefficiencies or the use of +NFS is discontinued for Git data, Rugged implementations of some of the +most commonly-used RPCs can be enabled via feature flags: + +* `rugged_find_commit` +* `rugged_get_tree_entries` +* `rugged_tree_entry` +* `rugged_commit_is_ancestor` + +A convenience Rake task can be used to enable or disable these flags +all together. To enable: + +```sh +bundle exec rake gitlab:features:enable_rugged +``` + +To disable: + +```sh +bundle exec rake gitlab:features:disable_rugged +``` + +Most of this code exists in the `lib/gitlab/git/rugged_impl` directory. + +NOTE: **Note:** You should NOT need to add or modify code related to +Rugged unless explicitly discussed with the [Gitaly +Team](https://gitlab.com/groups/gl-gitaly/group_members). This code will +NOT work on GitLab.com or other GitLab instances that do not use NFS. + ## `TooManyInvocationsError` errors During development and testing, you may experience `Gitlab::GitalyClient::TooManyInvocationsError` failures. diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md index 2bd8332bf93..cfe0e6f70fc 100644 --- a/doc/development/testing_guide/best_practices.md +++ b/doc/development/testing_guide/best_practices.md @@ -40,7 +40,7 @@ bundle exec rspec spec/[path]/[to]/[spec].rb to separate phases. - Use `Gitlab.config.gitlab.host` rather than hard coding `'localhost'` - Don't assert against the absolute value of a sequence-generated attribute (see - [Gotchas](../gotchas.md#dont-assert-against-the-absolute-value-of-a-sequence-generated-attribute)). + [Gotchas](../gotchas.md#do-not-assert-against-the-absolute-value-of-a-sequence-generated-attribute)). - Don't supply the `:each` argument to hooks since it's the default. - On `before` and `after` hooks, prefer it scoped to `:context` over `:all` - When using `evaluate_script("$('.js-foo').testSomething()")` (or `execute_script`) which acts on a given element, diff --git a/doc/development/testing_guide/testing_levels.md b/doc/development/testing_guide/testing_levels.md index a7a3459719b..5d46833a1e2 100644 --- a/doc/development/testing_guide/testing_levels.md +++ b/doc/development/testing_guide/testing_levels.md @@ -46,7 +46,7 @@ They're useful to test permissions, redirections, what view is rendered etc. | `app/mailers/` | `spec/mailers/` | RSpec | | | `lib/api/` | `spec/requests/api/` | RSpec | | | `lib/ci/api/` | `spec/requests/ci/api/` | RSpec | | -| `app/assets/javascripts/` | `spec/javascripts/` | Karma | More details in the [JavaScript](#javascript) section. | +| `app/assets/javascripts/` | `spec/javascripts/` | Karma | More details in the [Karma JavaScript test suite](frontend_testing.md#karma-test-suite) section. | ### About controller tests @@ -210,7 +210,7 @@ trade-off: - Integration tests are a bit more expensive, but don't abuse them. A system test is often better than an integration test that is stubbing a lot of internals. - System tests are expensive (compared to unit tests), even more if they require - a JavaScript driver. Make sure to follow the guidelines in the [Speed](#test-speed) + a JavaScript driver. Make sure to follow the guidelines in the [Speed](best_practices.md#test-speed) section. Another way to see it is to think about the "cost of tests", this is well diff --git a/doc/gitlab-basics/create-project.md b/doc/gitlab-basics/create-project.md index 978ffde84ad..3d4259ab7d3 100644 --- a/doc/gitlab-basics/create-project.md +++ b/doc/gitlab-basics/create-project.md @@ -42,7 +42,7 @@ Project templates can pre-populate your project with necessary files to get you There are two types of project templates: -- [Built-in templates](#builtin-templates), sourced from the [`project-templates`](https://gitlab.com/gitlab-org/project-templates) group. +- [Built-in templates](#built-in-templates), sourced from the [`project-templates`](https://gitlab.com/gitlab-org/project-templates) group. - [Custom project templates](#custom-project-templates-premium-only), for custom templates configured by GitLab administrators and users. ### Built-in templates diff --git a/doc/install/aws/index.md b/doc/install/aws/index.md index ce50b5fa317..2fcc9b90157 100644 --- a/doc/install/aws/index.md +++ b/doc/install/aws/index.md @@ -610,7 +610,7 @@ To back up GitLab: To restore GitLab, first review the [restore documentation](../../raketasks/backup_restore.md#restore), and primarily the restore prerequisites. Then, follow the steps under the -[Omnibus installations section](../../raketasks/backup_restore.md#restore-for-omnibus-installations). +[Omnibus installations section](../../raketasks/backup_restore.md#restore-for-omnibus-gitlab-installations). ## Updating GitLab diff --git a/doc/install/docker.md b/doc/install/docker.md index d0129f0f5c4..4568a949b0a 100644 --- a/doc/install/docker.md +++ b/doc/install/docker.md @@ -2,7 +2,7 @@ [Docker](https://www.docker.com) and container technology have been revolutionizing the software world for the past few years. They combine the performance and efficiency of native execution with the abstraction, security, and immutability of virtualization. -GitLab provides official Docker images to allowing you to easily take advantage of the benefits of containerization while operating your GitLab instance. +GitLab provides official Docker images allowing you to easily take advantage of the benefits of containerization while operating your GitLab instance. ## Omnibus GitLab based images diff --git a/doc/integration/omniauth.md b/doc/integration/omniauth.md index 4db986197f3..69bbd05c367 100644 --- a/doc/integration/omniauth.md +++ b/doc/integration/omniauth.md @@ -199,7 +199,7 @@ from the Omniauth provider's documentation. sudo -u git -H bundle install --without development test mysql --path vendor/bundle --no-deployment - > These are the same commands you used in the [Install Gems section](#install-gems) with `--path vendor/bundle --no-deployment` instead of `--deployment`. + > These are the same commands you used during initial installation in the [Install Gems section](../install/installation.md#install-gems) with `--path vendor/bundle --no-deployment` instead of `--deployment`. - Start GitLab: diff --git a/doc/topics/authentication/index.md b/doc/topics/authentication/index.md index df6897002c9..eef26612d5b 100644 --- a/doc/topics/authentication/index.md +++ b/doc/topics/authentication/index.md @@ -35,7 +35,7 @@ This page gathers all the resources for the topic **Authentication** within GitL ## API -- [OAuth 2 Tokens](../../api/README.md#oauth-2-tokens) +- [OAuth 2 Tokens](../../api/README.md#oauth2-tokens) - [Personal access tokens](../../api/README.md#personal-access-tokens) - [Impersonation tokens](../../api/README.md#impersonation-tokens) - [GitLab as an OAuth2 provider](../../api/oauth2.md#gitlab-as-an-oauth2-provider) diff --git a/doc/update/restore_after_failure.md b/doc/update/restore_after_failure.md index faa3a6e65cb..964a3c76c04 100644 --- a/doc/update/restore_after_failure.md +++ b/doc/update/restore_after_failure.md @@ -12,7 +12,7 @@ First, roll back the code or package. For source installations this involves checking out the older version (branch or tag). For Omnibus installations this means installing the older .deb or .rpm package. Then, restore from a backup. Follow the instructions in the -[Backup and Restore](../raketasks/backup_restore.md#restore-a-previously-created-backup) +[Backup and Restore](../raketasks/backup_restore.md#restore) documentation. ## Potential problems on the next upgrade diff --git a/doc/user/admin_area/monitoring/health_check.md b/doc/user/admin_area/monitoring/health_check.md index c22982ac190..e183898dfb1 100644 --- a/doc/user/admin_area/monitoring/health_check.md +++ b/doc/user/admin_area/monitoring/health_check.md @@ -1,11 +1,11 @@ # Health Check > **Notes:** + > - Liveness and readiness probes were [introduced][ce-10416] in GitLab 9.1. -> - The `health_check` endpoint was [introduced][ce-3888] in GitLab 8.8 and will -> be deprecated in GitLab 9.1. Read more in the [old behavior](#old-behavior) -> section. -> - [Access token](#access-token) has been deprecated in GitLab 9.4 +> - The `health_check` endpoint was [introduced][ce-3888] in GitLab 8.8 and was +> be deprecated in GitLab 9.1. +> - [Access token](#access-token-deprecated) has been deprecated in GitLab 9.4 > in favor of [IP whitelist](#ip-whitelist) GitLab provides liveness and readiness probes to indicate service health and @@ -16,21 +16,19 @@ traffic until the system is ready or restart the container as needed. ## IP whitelist -To access monitoring resources, the client IP needs to be included in a whitelist. +To access monitoring resources, the requesting client IP needs to be included in a whitelist. [Read how to add IPs to a whitelist for the monitoring endpoints][admin]. ## Using the endpoints -With default whitelist settings, the probes can be accessed from localhost: +With default whitelist settings, the probes can be accessed from localhost using the following URLs: - `http://localhost/-/health` - `http://localhost/-/readiness` - `http://localhost/-/liveness` -The first endpoint, `/-/health/`, only checks whether the application server is running. It does --not verify the database or other services are running. A successful response will return -a 200 status code with the following message: +The first endpoint, `health`, only checks whether the application server is running. It does not verify the database or other services are running. A successful response will return a 200 status code with the following message: ``` GitLab OK @@ -38,9 +36,9 @@ GitLab OK The readiness and liveness probes will provide a report of system health in JSON format. -Readiness example output: +`readiness` probe example output: -``` +```json { "queues_check" : { "status" : "ok" @@ -60,9 +58,9 @@ Readiness example output: } ``` -Liveness example output: +`liveness` probe example output: -``` +```json { "cache_check" : { "status" : "ok" diff --git a/doc/user/group/clusters/index.md b/doc/user/group/clusters/index.md index 8d223d1c5f0..8cdfb13a97b 100644 --- a/doc/user/group/clusters/index.md +++ b/doc/user/group/clusters/index.md @@ -56,7 +56,7 @@ group. That way you can have different clusters for different environments, like dev, staging, production, etc. Add another cluster similar to the first one and make sure to -[set an environment scope](#environment-scopes) that will +[set an environment scope](#environment-scopes-premium) that will differentiate the new cluster from the rest. ## Base domain @@ -133,4 +133,4 @@ The following features are not currently available for group-level clusters: 1. Terminals (see [related issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/55487)). 1. Pod logs (see [related issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/55488)). -1. Deployment boards (see [related issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/55488)). +1. Deployment boards (see [related issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/55489)). diff --git a/doc/user/group/index.md b/doc/user/group/index.md index 300e0115c60..67b93ed6666 100644 --- a/doc/user/group/index.md +++ b/doc/user/group/index.md @@ -154,7 +154,7 @@ There are two different ways to add a new project to a group: ## Transfer projects into groups -Learn how to [transfer a project into a group](../project/index.md#transfer-an-existing-project-into-a-group). +Learn how to [transfer a project into a group](../project/settings/index.md#transferring-an-existing-project-into-another-namespace). ## Sharing a project with a group diff --git a/doc/user/group/subgroups/index.md b/doc/user/group/subgroups/index.md index b6f8f55978b..3cecefe11f5 100644 --- a/doc/user/group/subgroups/index.md +++ b/doc/user/group/subgroups/index.md @@ -1,8 +1,8 @@ # Subgroups NOTE: **Note:** -[Introduced][ce-2772] in GitLab 9.0. Not available when using MySQL as external -database (support removed in GitLab 9.3 [due to performance reasons][issue]). +[Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/2772) in GitLab 9.0. Not available when using MySQL as external +database (support removed in GitLab 9.3 [due to performance reasons](https://gitlab.com/gitlab-org/gitlab-ce/issues/30472#note_27747600)). With subgroups (aka nested groups or hierarchical groups) you can have up to 20 levels of nested groups, which among other things can help you to: @@ -13,7 +13,7 @@ up to 20 levels of nested groups, which among other things can help you to: - **Organize large projects.** For large projects, subgroups makes it potentially easier to separate permissions on parts of the source code. - **Make it easier to manage people and control visibility.** Give people - different [permissions][] depending on their group [membership](#membership). + different [permissions](../../permissions.md#group-members-permissions) depending on their group [membership](#membership). ## Database Requirements @@ -80,9 +80,9 @@ structure. NOTE: **Note:** You need to be an Owner of a group in order to be able to create a subgroup. For -more information check the [permissions table][permissions]. +more information check the [permissions table](../../permissions.md#group-members-permissions). For a list of words that are not allowed to be used as group names see the -[reserved names][reserved]. +[reserved names](../../reserved_names.md). Users can always create subgroups if they are explicitly added as an Owner to a parent group even if group creation is disabled by an administrator in their settings. @@ -176,6 +176,6 @@ Here's a list of what you can't do with subgroups: `group/subgroup01/subgroup03`. [ce-2772]: https://gitlab.com/gitlab-org/gitlab-ce/issues/2772 -[permissions]: ../../permissions.md#group +[permissions]: ../../permissions.md#group-members-permissions [reserved]: ../../reserved_names.md [issue]: https://gitlab.com/gitlab-org/gitlab-ce/issues/30472#note_27747600 diff --git a/doc/user/index.md b/doc/user/index.md index 71378920ed4..b84879601ff 100644 --- a/doc/user/index.md +++ b/doc/user/index.md @@ -8,13 +8,13 @@ Welcome to GitLab! We're glad to have you here! As a GitLab user you'll have access to all the features your [subscription](https://about.gitlab.com/pricing/) -includes, except [GitLab administrator](../README.md#administrator-documentation) +includes, except [GitLab administrator](../administration/index.md) settings, unless you have admin privileges to install, configure, and upgrade your GitLab instance. Admin privileges for [GitLab.com](https://gitlab.com/) are restricted to the GitLab team. -For more information on configuring GitLab self-managed instances, see [Administrator documentation](../README.md#administrator-documentation). +For more information on configuring GitLab self-managed instances, see [Administrator documentation](../administration/index.md). ## Overview diff --git a/doc/user/instance_statistics/convdev.md b/doc/user/instance_statistics/convdev.md index ddf34b19a5a..247be1fb392 100644 --- a/doc/user/instance_statistics/convdev.md +++ b/doc/user/instance_statistics/convdev.md @@ -1,9 +1,9 @@ # Conversational Development Index -> [Introduced][ce-30469] in GitLab 9.3. +> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/30469) in GitLab 9.3. NOTE: **NOTE** -Your GitLab instance's [usage ping][ping] must be activated in order to use this feature. +Your GitLab instance's [usage ping](../admin_area/settings/usage_statistics.md#usage-ping-core-only) must be activated in order to use this feature. The Conversational Development Index (ConvDev Index) gives you an overview of your entire instance's adoption of [Concurrent DevOps](https://about.gitlab.com/concurrent-devops/) @@ -12,7 +12,7 @@ from planning to monitoring. This displays the usage of these GitLab features 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][ping] that GitLab has +of top-performing instances based on [usage ping data](../admin_area/settings/usage_statistics.md#usage-ping-core-only) 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 index score is an average of all your feature score percentages - this percentage value is presented above all the of features on the page. @@ -24,6 +24,3 @@ improve your scores. Usage ping data is aggregated on GitLab's 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. - -[ce-30469]: https://gitlab.com/gitlab-org/gitlab-ce/issues/30469 -[ping]: ../admin_area/settings/usage_statistics.md#usage-ping diff --git a/doc/user/permissions.md b/doc/user/permissions.md index ea3e9d0cce9..ee3367f193c 100644 --- a/doc/user/permissions.md +++ b/doc/user/permissions.md @@ -14,7 +14,7 @@ be able to create issues, leave comments, and clone or download the project code When a member leaves the team all the assigned [Issues](project/issues/index.md) and [Merge Requests](project/merge_requests/index.md) will be unassigned automatically. -GitLab [administrators](../README.md#administrator-documentation) receive all permissions. +GitLab [administrators](../administration/index.md) receive all permissions. To add or import a user, you can follow the [project members documentation](../user/project/members/index.md). diff --git a/doc/user/profile/active_sessions.md b/doc/user/profile/active_sessions.md index 5119c0e30d0..28e3f4904a9 100644 --- a/doc/user/profile/active_sessions.md +++ b/doc/user/profile/active_sessions.md @@ -4,7 +4,7 @@ > in GitLab 10.8. GitLab lists all devices that have logged into your account. This allows you to -review the sessions and revoke any of it that you don't recognize. +review the sessions. ## Listing all active sessions @@ -12,9 +12,3 @@ review the sessions and revoke any of it that you don't recognize. 1. Navigate to the **Active Sessions** tab.  - -## Revoking a session - -1. Navigate to your [profile's](#profile-settings) **Settings > Active Sessions**. -1. Click on **Revoke** besides a session. The current session cannot be - revoked, as this would sign you out of GitLab. diff --git a/doc/user/profile/img/active_sessions_list.png b/doc/user/profile/img/active_sessions_list.png Binary files differindex 5d94dca69cc..1e242ac4710 100644 --- a/doc/user/profile/img/active_sessions_list.png +++ b/doc/user/profile/img/active_sessions_list.png diff --git a/doc/user/profile/index.md b/doc/user/profile/index.md index a2b15d058d7..b216b9f255c 100644 --- a/doc/user/profile/index.md +++ b/doc/user/profile/index.md @@ -39,7 +39,7 @@ From there, you can: - Manage [personal access tokens](personal_access_tokens.md) to access your account via API and authorized applications - Add and delete emails linked to your account - Choose which email to use for notifications, web-based commits, and display on your public profile -- Manage [SSH keys](../../ssh/README.md#ssh) to access your account via SSH +- Manage [SSH keys](../../ssh/README.md) to access your account via SSH - Manage your [preferences](preferences.md#syntax-highlighting-theme) to customize your own GitLab experience - [View your active sessions](active_sessions.md) and revoke any of them if necessary diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md index 0c514e005b2..6e64053a6ca 100644 --- a/doc/user/project/clusters/index.md +++ b/doc/user/project/clusters/index.md @@ -88,7 +88,7 @@ To add an existing Kubernetes cluster to your project: 1. Click **Add an existing Kubernetes cluster** and fill in the details: - **Kubernetes cluster name** (required) - The name you wish to give the cluster. - **Environment scope** (required) - The - [associated environment](#setting-the-environment-scope) to this cluster. + [associated environment](#setting-the-environment-scope-premium) to this cluster. - **API URL** (required) - It's the URL that GitLab uses to access the Kubernetes API. Kubernetes exposes several APIs, we want the "base" URL that is common to all of them, @@ -473,7 +473,7 @@ project. That way you can have different clusters for different environments, like dev, staging, production, etc. Simply add another cluster, like you did the first time, and make sure to -[set an environment scope](#setting-the-environment-scope) that will +[set an environment scope](#setting-the-environment-scope-premium) that will differentiate the new cluster with the rest. ## Setting the environment scope **[PREMIUM]** diff --git a/doc/user/project/clusters/serverless/index.md b/doc/user/project/clusters/serverless/index.md index 2871510d5ed..856ae03f4bc 100644 --- a/doc/user/project/clusters/serverless/index.md +++ b/doc/user/project/clusters/serverless/index.md @@ -114,28 +114,35 @@ Follow these steps to deploy a function using the Node.js runtime to your Knativ - Public, continue to the next step. - Private, you will need to [create a GitLab deploy token](../../deploy_tokens/index.md#creating-a-deploy-token) with `gitlab-deploy-token` as the name and the `read_registry` scope. -1. `.gitlab-ci.yml`: This template allows to define the stage, environment, and - image to be used for your functions. It must be included at the root of your repository: +1. `.gitlab-ci.yml`: this defines a pipeline used to deploy your functions. + It must be included at the root of your repository: ```yaml - stages: - - deploy + include: + template: Serverless.gitlab-ci.yml functions: - stage: deploy - environment: test - image: gcr.io/triggermesh/tm:v0.0.9 - script: - - tm -n "$KUBE_NAMESPACE" set registry-auth gitlab-registry --registry "$CI_REGISTRY" --username "$CI_REGISTRY_USER" --password "$CI_JOB_TOKEN" --push - - tm -n "$KUBE_NAMESPACE" set registry-auth gitlab-registry --registry "$CI_REGISTRY" --username "$CI_DEPLOY_USER" --password "$CI_DEPLOY_PASSWORD" --pull - - tm -n "$KUBE_NAMESPACE" deploy --wait - + extends: .serverless:deploy:functions + environment: production ``` - The `gitlab-ci.yml` template creates a `Deploy` stage with a `functions` job that invokes the `tm` CLI with the required parameters. + This `.gitlab-ci.yml` creates a `functions` job that invokes some + predefined commands to deploy your functions to your cluster. + + `Serverless.gitlab-ci.yml` is a template that allows customization. + You can either import it with `include` parameter and use `extends` to + customize your jobs, or you can inline the entire template by choosing it + from **Apply a template** dropdown when editing the `.gitlab-ci.yml` file through + the user interface. + +2. `serverless.yml`: this file contains the metadata for your functions, + such as name, runtime, and environment. -2. `serverless.yml`: This file contains the metadata for your functions, - such as name, runtime, and environment. It must be included at the root of your repository. The following is a sample `echo` function which shows the required structure for the file. You can find the relevant files for this project in the [functions example project](https://gitlab.com/knative-examples/functions). + It must be included at the root of your repository. + The following is a sample `echo` function which shows the required structure + for the file. + + You can find the relevant files for this project in the [functions example project](https://gitlab.com/knative-examples/functions). ```yaml service: my-functions @@ -234,32 +241,22 @@ Add the following `.gitlab-ci.yml` to the root of your repository (you may skip this step if you've previously cloned the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) mentioned above): ```yaml -stages: - - build - - deploy +include: + template: Serverless.gitlab-ci.yml build: - stage: build - image: - name: gcr.io/kaniko-project/executor:debug - entrypoint: [""] - only: - - master - script: - - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json - - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE + extends: .serverless:build:image deploy: - stage: deploy - image: gcr.io/triggermesh/tm@sha256:e3ee74db94d215bd297738d93577481f3e4db38013326c90d57f873df7ab41d5 - only: - - master - environment: production - script: - - echo "$CI_REGISTRY_IMAGE" - - tm -n "$KUBE_NAMESPACE" --config "$KUBECONFIG" deploy service "$CI_PROJECT_NAME" --from-image "$CI_REGISTRY_IMAGE" --wait + extends: .serverless:deploy:image ``` +`Serverless.gitlab-ci.yml` is a template that allows customization. +You can either import it with `include` parameter and use `extends` to +customize your jobs, or you can inline the entire template by choosing it +from **Apply a template** dropdown when editing the `.gitlab-ci.yml` file through +the user interface. + ### Deploy the application with Knative With all the pieces in place, the next time a CI pipeline runs, the Knative application will be deployed. Navigate to diff --git a/doc/user/project/import/svn.md b/doc/user/project/import/svn.md index a5923986292..4825b005a85 100644 --- a/doc/user/project/import/svn.md +++ b/doc/user/project/import/svn.md @@ -8,7 +8,7 @@ between the two, for more information consult your favorite search engine. There are two approaches to SVN to Git migration: -1. [Git/SVN Mirror](#smooth-migration-with-a-git-svn-mirror-using-subgit) which: +1. [Git/SVN Mirror](#smooth-migration-with-a-gitsvn-mirror-using-subgit) which: - Makes the GitLab repository to mirror the SVN project. - Git and SVN repositories are kept in sync; you can use either one. - Smoothens the migration process and allows to manage migration risks. diff --git a/doc/user/project/index.md b/doc/user/project/index.md index 0dc50d28cb0..4148310dc98 100644 --- a/doc/user/project/index.md +++ b/doc/user/project/index.md @@ -137,7 +137,7 @@ and Git push/pull redirects. Depending on the situation, different things apply. When [renaming a user](../profile/index.md#changing-your-username), -[changing a group path](../group/index.md#changing-a-group-s-path) or [renaming a repository](settings/index.md#renaming-a-repository): +[changing a group path](../group/index.md#changing-a-groups-path) or [renaming a repository](settings/index.md#renaming-a-repository): - Existing web URLs for the namespace and anything under it (e.g., projects) will redirect to the new URLs. diff --git a/doc/user/project/integrations/mattermost_slash_commands.md b/doc/user/project/integrations/mattermost_slash_commands.md index e031dcad2c3..9c69437537a 100644 --- a/doc/user/project/integrations/mattermost_slash_commands.md +++ b/doc/user/project/integrations/mattermost_slash_commands.md @@ -152,7 +152,7 @@ trigger word followed by <kbd>help</kbd>. Example: <samp>/gitlab help</samp> ## Permissions The permissions to run the [available commands](#available-slash-commands) derive from -the [permissions you have on the project](../../permissions.md#project). +the [permissions you have on the project](../../permissions.md#project-members-permissions). ## Further reading diff --git a/doc/user/project/integrations/prometheus.md b/doc/user/project/integrations/prometheus.md index ed289b0c4eb..26989e2a8a4 100644 --- a/doc/user/project/integrations/prometheus.md +++ b/doc/user/project/integrations/prometheus.md @@ -120,7 +120,7 @@ If the "No data found" screen continues to appear, it could be due to: - No successful deployments have occurred to this environment. - Prometheus does not have performance data for this environment, or the metrics are not labeled correctly. To test this, connect to the Prometheus server and - [run a query](#gitlab-prometheus-queries), replacing `$CI_ENVIRONMENT_SLUG` + [run a query](prometheus_library/kubernetes.html#metrics-supported), replacing `$CI_ENVIRONMENT_SLUG` with the name of your environment. [autodeploy]: ../../../ci/autodeploy/index.md diff --git a/doc/user/project/operations/error_tracking.md b/doc/user/project/operations/error_tracking.md index 41aa5b91aa7..1b319c5641c 100644 --- a/doc/user/project/operations/error_tracking.md +++ b/doc/user/project/operations/error_tracking.md @@ -22,8 +22,12 @@ GitLab provides an easy way to connect Sentry to your project: 1. Sign up to Sentry.io or [deploy your own](#deploying-sentry) Sentry instance. 1. [Find or generate](https://docs.sentry.io/api/auth/) a Sentry auth token for your Sentry project. Make sure to give the token at least the following scopes: `event:read` and `project:read`. -1. Navigate to your project’s **Settings > Operations** and provide the Sentry API URL and auth token. -1. Ensure that the 'Active' checkbox is set. +1. Navigate to your project’s **Settings > Operations**. +1. Ensure that the **Active** checkbox is set. +1. In the **Sentry API URL** field, enter your Sentry hostname. For example, `https://sentry.example.com`. +1. In the **Auth Token** field, enter the token you previously generated. +1. Click the **Connect** button to test the connection to Sentry and populate the **Project** dropdown. +1. From the **Project** dropdown, choose a Sentry project to link to your GitLab project. 1. Click **Save changes** for the changes to take effect. 1. You can now visit **Operations > Error Tracking** in your project's sidebar to [view a list](#error-tracking-list) of Sentry errors. diff --git a/doc/user/project/pages/getting_started_part_one.md b/doc/user/project/pages/getting_started_part_one.md index 9a95fb70964..f1e2771dcb9 100644 --- a/doc/user/project/pages/getting_started_part_one.md +++ b/doc/user/project/pages/getting_started_part_one.md @@ -59,7 +59,7 @@ which is highly recommendable and much faster than hardcoding. If you set up a GitLab Pages project on GitLab.com, it will automatically be accessible under a -[subdomain of `namespace.gitlab.io`](introduction.md#gitlab-pages-on-gitlab-com). +[subdomain of `namespace.gitlab.io`](introduction.md#gitlab-pages-on-gitlabcom). The `namespace` is defined by your username on GitLab.com, or the group name you created this project under. diff --git a/doc/user/project/pages/getting_started_part_three.md b/doc/user/project/pages/getting_started_part_three.md index daae2f4b5a3..756b8b698c7 100644 --- a/doc/user/project/pages/getting_started_part_three.md +++ b/doc/user/project/pages/getting_started_part_three.md @@ -20,13 +20,13 @@ you should consider first, which we'll cover in this guide: 1. Either if you're adding a **root domain** or a **subdomain**, for which you'll need to set up [DNS records](#dns-records) -1. Whether you want to add an [SSL/TLS certificate](#ssl-tls-certificates) or not +1. Whether you want to add an [SSL/TLS certificate](#ssltls-certificates) or not To finish the association, you need to [add your domain to your project's Pages settings](#add-your-custom-domain-to-gitlab-pages-settings). Let's start from the beginning with [DNS records](#dns-records). If you already know how they work and want to skip the introduction to DNS, -you may be interested in skipping it until the [TL;DR](#tl-dr) section below. +you may be interested in skipping it until the [TL;DR](#tldr) section below. ### DNS Records @@ -148,7 +148,7 @@ verify your domain's ownership with a TXT record: Once you've set the DNS record, you'll need navigate to your project's **Setting > Pages** and click **+ New domain** to add your custom domain to -GitLab Pages. You can choose whether to add an [SSL/TLS certificate](#ssl-tls-certificates) +GitLab Pages. You can choose whether to add an [SSL/TLS certificate](#ssltls-certificates) to make your website accessible under HTTPS or leave it blank. If don't add a certificate, your site will be accessible only via HTTP: diff --git a/doc/user/project/pages/index.md b/doc/user/project/pages/index.md index e0b78753e21..ee471fa6534 100644 --- a/doc/user/project/pages/index.md +++ b/doc/user/project/pages/index.md @@ -141,7 +141,7 @@ You can also take some optional further steps: _Advanced options:_ - [Use a custom domain](getting_started_part_three.md#adding-your-custom-domain-to-gitlab-pages) -- Apply [SSL/TLS certification](getting_started_part_three.md#ssl-tls-certificates) to your custom domain +- Apply [SSL/TLS certification](getting_started_part_three.md#ssltls-certificates) to your custom domain ## Explore GitLab Pages diff --git a/doc/user/project/pages/introduction.md b/doc/user/project/pages/introduction.md index 23eb88fd305..6bb58689f38 100644 --- a/doc/user/project/pages/introduction.md +++ b/doc/user/project/pages/introduction.md @@ -11,7 +11,7 @@ With GitLab Pages you can host for free your static websites on GitLab. Combined with the power of [GitLab CI] and the help of [GitLab Runner] you can deploy static pages for your individual projects, your user or your group. -Read [GitLab Pages on GitLab.com](#gitlab-pages-on-gitlab-com) for specific +Read [GitLab Pages on GitLab.com](#gitlab-pages-on-gitlabcom) for specific information, if you are using GitLab.com to host your website. ## Getting started with GitLab Pages domains @@ -410,7 +410,7 @@ file for both the `/data` and `/data/` URL paths. ### Add a custom domain to your Pages website For a complete guide on Pages domains, read through the article -[GitLab Pages from A to Z: Part 3 - Setting Up Custom Domains - DNS Records and SSL/TLS Certificates](getting_started_part_three.md#setting-up-custom-domains-dns-records-and-ssl-tls-certificates) +[GitLab Pages from A to Z: Part 3 - GitLab Pages custom domains and SSL/TLS Certificates](getting_started_part_three.md) If this setting is enabled by your GitLab administrator, you should be able to see the **New Domain** button when visiting your project's settings through the @@ -451,7 +451,7 @@ private key when adding a new domain.  For a complete guide on Pages domains, read through the article -[GitLab Pages from A to Z: Part 3 - Setting Up Custom Domains - DNS Records and SSL/TLS Certificates](getting_started_part_three.md#setting-up-custom-domains-dns-records-and-ssl-tls-certificates) +[GitLab Pages from A to Z: Part 3 - GitLab Pages custom domains and SSL/TLS Certificates](getting_started_part_three.md) ### Custom error codes pages diff --git a/doc/user/project/pipelines/job_artifacts.md b/doc/user/project/pipelines/job_artifacts.md index bf939dbdaa3..8b57129c9e1 100644 --- a/doc/user/project/pipelines/job_artifacts.md +++ b/doc/user/project/pipelines/job_artifacts.md @@ -38,7 +38,7 @@ turn are defined with the `paths` keyword. All paths to files and directories are relative to the repository that was cloned during the build. These uploaded artifacts will be kept in GitLab for 1 week as defined by the `expire_in` definition. You have the option to keep the artifacts from expiring via the -[web interface](#browsing-job-artifacts). If the expiry time is not defined, +[web interface](#browsing-artifacts). If the expiry time is not defined, it defaults to the [instance wide setting](../../admin_area/settings/continuous_integration.md#default-artifacts-expiration-core-only). diff --git a/doc/user/project/repository/branches/index.md b/doc/user/project/repository/branches/index.md index f05554ffc5b..13e4f2ce163 100644 --- a/doc/user/project/repository/branches/index.md +++ b/doc/user/project/repository/branches/index.md @@ -11,7 +11,7 @@ Read through GiLab's branching documentation: See also: - [Branches API](../../../../api/branches.md), for information on operating on repository branches using the GitLab API. -- [GitLab Flow](../../../../university/training/gitlab_flow.md#gitlab-flow). Use the best of GitLab for your branching strategies. +- [GitLab Flow](../../../../university/training/gitlab_flow.md). Use the best of GitLab for your branching strategies. - [Getting started with Git](../../../../topics/git/index.md) and GitLab. ## Default branch diff --git a/doc/user/search/index.md b/doc/user/search/index.md index 770cef42995..705983cce2a 100644 --- a/doc/user/search/index.md +++ b/doc/user/search/index.md @@ -96,7 +96,7 @@ quickly access issues and merge requests created or assigned to you within that Your [todos](../../workflow/todos.md#gitlab-todos) can be searched by "to do" and "done". You can [filter](../../workflow/todos.md#filtering-your-todos) them per project, author, type, and action. Also, you can sort them by -[**Label priority**](../../user/project/labels.md#prioritize-labels), +[**Label priority**](../../user/project/labels.md#label-priority), **Last created** and **Oldest created**. ## Projects diff --git a/doc/workflow/groups.md b/doc/workflow/groups.md index 06eec1ed928..c7f4647baa9 100644 --- a/doc/workflow/groups.md +++ b/doc/workflow/groups.md @@ -1,2 +1,5 @@ +--- +redirect_to: '../user/group/index.md' +--- This document was moved to [another location](../user/group/index.md). |
