Add latest changes from gitlab-org/gitlab@master

doc/ci/pipelines/schedules.md

@@ -12,7 +12,7 @@ Cron notation is parsed by [Fugit](https://github.com/floraison/fugit).
 Pipelines are normally run based on certain conditions being met. For example, when a branch is pushed to repository.
-Pipeline schedules can be used to also run [pipelines](../pipelines.md) at specific intervals. For example:
+Pipeline schedules can be used to also run [pipelines](index.md) at specific intervals. For example:
 - Every month on the 22nd for a certain branch.
 - Once every day.

doc/ci/pipelines/settings.md

+---
+type: reference, howto
+---
+
+# Pipelines settings
+
+To reach the pipelines settings navigate to your project's
+**Settings > CI/CD**.
+
+The following settings can be configured per project.
+
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
+For an overview, watch the video [GitLab CI Pipeline, Artifacts, and Environments](https://www.youtube.com/watch?v=PCKDICEe10s).
+Watch also [GitLab CI pipeline tutorial for beginners](https://www.youtube.com/watch?v=Jav4vbUrqII).
+
+## Git strategy
+
+With Git strategy, you can choose the default way your repository is fetched
+from GitLab in a job.
+
+There are two options. Using:
+
+- `git clone`, which is slower since it clones the repository from scratch
+  for every job, ensuring that the local working copy is always pristine.
+- `git fetch`, which is faster as it re-uses the local working copy (falling
+  back to clone if it doesn't exist).
+
+The default Git strategy can be overridden by the [GIT_STRATEGY variable](../yaml/README.md#git-strategy)
+in `.gitlab-ci.yml`.
+
+## Git shallow clone
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/28919) in GitLab 12.0.
+
+NOTE: **Note**:
+As of GitLab 12.0, newly created projects will automatically have a default
+`git depth` value of `50`.
+
+It is possible to limit the number of changes that GitLab CI/CD will fetch when cloning
+a repository. Setting a limit to `git depth` can speed up Pipelines execution. Maximum
+allowed value is `1000`.
+
+To disable shallow clone and make GitLab CI/CD fetch all branches and tags each time,
+keep the value empty or set to `0`.
+
+This value can also be [overridden by `GIT_DEPTH`](../large_repositories/index.md#shallow-cloning) variable in `.gitlab-ci.yml` file.
+
+## Timeout
+
+Timeout defines the maximum amount of time in minutes that a job is able run.
+This is configurable under your project's **Settings > CI/CD > General pipelines settings**.
+The default value is 60 minutes. Decrease the time limit if you want to impose
+a hard limit on your jobs' running time or increase it otherwise. In any case,
+if the job surpasses the threshold, it is marked as failed.
+
+### Timeout overriding on Runner level
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17221) in GitLab 10.7.
+
+Project defined timeout (either specific timeout set by user or the default
+60 minutes timeout) may be [overridden on Runner level](../runners/README.md#setting-maximum-job-timeout-for-a-runner).
+
+## Maximum artifacts size **(CORE ONLY)**
+
+For information about setting a maximum artifact size for a project, see
+[Maximum artifacts size](../../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size-core-only).
+
+## Custom CI configuration path
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/12509) in GitLab 9.4.
+> - [Support for external `.gitlab-ci.yml` locations](https://gitlab.com/gitlab-org/gitlab/issues/14376) introduced in GitLab 12.6.
+
+By default we look for the `.gitlab-ci.yml` file in the project's root
+directory. If needed, you can specify an alternate path and file name, including locations outside the project.
+
+To customize the path:
+
+1. Go to the project's **Settings > CI / CD**.
+1. Expand the **General pipelines** section.
+1. Provide a value in the **Custom CI configuration path** field.
+1. Click **Save changes**.
+
+If the CI configuration is stored within the repository in a non-default
+location, the path must be relative to the root directory. Examples of valid
+paths and file names include:
+
+- `.gitlab-ci.yml` (default)
+- `.my-custom-file.yml`
+- `my/path/.gitlab-ci.yml`
+- `my/path/.my-custom-file.yml`
+
+If the CI configuration will be hosted on an external site, the URL link must end with `.yml`:
+
+- `http://example.com/generate/ci/config.yml`
+
+If the CI configuration will be hosted in a different project within GitLab, the path must be relative
+to the root directory in the other project, with the group and project name added to the end:
+
+- `.gitlab-ci.yml@mygroup/another-project`
+- `my/path/.my-custom-file.yml@mygroup/another-project`
+
+Hosting the configuration file in a separate project allows stricter control of the
+configuration file. For example:
+
+- Create a public project to host the configuration file.
+- Give write permissions on the project only to users who are allowed to edit the file.
+
+Other users and projects will be able to access the configuration file without being
+able to edit it.
+
+## Test coverage parsing
+
+If you use test coverage in your code, GitLab can capture its output in the
+job log using a regular expression. In the pipelines settings, search for the
+"Test coverage parsing" section.
+
+![Pipelines settings test coverage](img/pipelines_settings_test_coverage.png)
+
+Leave blank if you want to disable it or enter a ruby regular expression. You
+can use <https://rubular.com> to test your regex.
+
+If the pipeline succeeds, the coverage is shown in the merge request widget and
+in the jobs table.
+
+![MR widget coverage](img/pipelines_test_coverage_mr_widget.png)
+
+![Build status coverage](img/pipelines_test_coverage_build.png)
+
+A few examples of known coverage tools for a variety of languages can be found
+in the pipelines settings page.
+
+### Removing color codes
+
+Some test coverage tools output with ANSI color codes that won't be
+parsed correctly by the regular expression and will cause coverage
+parsing to fail.
+
+If your coverage tool doesn't provide an option to disable color
+codes in the output, you can pipe the output of the coverage tool through a
+small one line script that will strip the color codes off.
+
+For example:
+
+```shell
+lein cloverage | perl -pe 's/\e\[?.*?[\@-~]//g'
+```
+
+## Visibility of pipelines
+
+Pipeline visibility is determined by:
+
+- Your current [user access level](../../user/permissions.md).
+- The **Public pipelines** project setting under your project's **Settings > CI/CD > General pipelines**.
+
+NOTE: **Note:**
+If the project visibility is set to **Private**, the [**Public pipelines** setting will have no effect](../enable_or_disable_ci.md#per-project-user-setting).
+
+This also determines the visibility of these related features:
+
+- Job output logs
+- Job artifacts
+- The [pipeline security dashboard](../../user/application_security/security_dashboard/index.md#pipeline-security-dashboard) **(ULTIMATE)**
+
+If **Public pipelines** is enabled (default):
+
+- For **public** projects, anyone can view the pipelines and related features.
+- For **internal** projects, any logged in user can view the pipelines
+  and related features.
+- For **private** projects, any project member (guest or higher) can view the pipelines
+  and related features.
+
+If **Public pipelines** is disabled:
+
+- For **public** projects, anyone can view the pipelines, but only members
+  (reporter or higher) can access the related features.
+- For **internal** projects, any logged in user can view the pipelines.
+  However, only members (reporter or higher) can access the job related features.
+- For **private** projects, only project members (reporter or higher)
+  can view the pipelines or access the related features.
+
+## Auto-cancel pending pipelines
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/9362) in GitLab 9.1.
+
+If you want all pending non-HEAD pipelines on branches to auto-cancel each time
+a new pipeline is created, such as after a Git push or manually from the UI,
+you can enable this in the project settings:
+
+1. Go to **{settings}** **Settings > CI / CD**.
+1. Expand **General Pipelines**.
+1. Check the **Auto-cancel redundant, pending pipelines** checkbox.
+1. Click **Save changes**.
+
+## Skip older, pending deployment jobs
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/25276) in GitLab 12.9.
+
+Your project may have multiple concurrent deployment jobs that are
+scheduled to run within the same time frame.
+
+This can lead to a situation where an older deployment job runs after a
+newer one, which may not be what you want.
+
+To avoid this scenario:
+
+1. Go to **{settings}** **Settings > CI / CD**.
+1. Expand **General pipelines**.
+1. Check the **Skip older, pending deployment jobs** checkbox.
+1. Click **Save changes**.
+
+The pending deployment jobs will be skipped.
+
+## Pipeline Badges
+
+In the pipelines settings page you can find pipeline status and test coverage
+badges for your project. The latest successful pipeline will be used to read
+the pipeline status and test coverage values.
+
+Visit the pipelines settings page in your project to see the exact link to
+your badges, as well as ways to embed the badge image in your HTML or Markdown
+pages.
+
+![Pipelines badges](img/pipelines_settings_badges.png)
+
+### Pipeline status badge
+
+Depending on the status of your job, a badge can have the following values:
+
+- pending
+- running
+- passed
+- failed
+- skipped
+- canceled
+- unknown
+
+You can access a pipeline status badge image using the following link:
+
+```text
+https://example.gitlab.com/<namespace>/<project>/badges/<branch>/pipeline.svg
+```
+
+### Test coverage report badge
+
+GitLab makes it possible to define the regular expression for [coverage report](#test-coverage-parsing),
+that each job log will be matched against. This means that each job in the
+pipeline can have the test coverage percentage value defined.
+
+The test coverage badge can be accessed using following link:
+
+```text
+https://example.gitlab.com/<namespace>/<project>/badges/<branch>/coverage.svg
+```
+
+If you would like to get the coverage report from a specific job, you can add
+the `job=coverage_job_name` parameter to the URL. For example, the following
+Markdown code will embed the test coverage report badge of the `coverage` job
+into your `README.md`:
+
+```markdown
+![coverage](https://gitlab.com/gitlab-org/gitlab-foss/badges/master/coverage.svg?job=coverage)
+```
+
+### Badge styles
+
+Pipeline badges can be rendered in different styles by adding the `style=style_name` parameter to the URL. Currently two styles are available:
+
+#### Flat (default)
+
+```text
+https://example.gitlab.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat
+```
+
+![Badge flat style](https://gitlab.com/gitlab-org/gitlab-foss/badges/master/coverage.svg?job=coverage&style=flat)
+
+#### Flat square
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/30120) in GitLab 11.8.
+
+```text
+https://example.gitlab.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat-square
+```
+
+![Badge flat square style](https://gitlab.com/gitlab-org/gitlab-foss/badges/master/coverage.svg?job=coverage&style=flat-square)
+
+## Environment Variables
+
+[Environment variables](../variables/README.md#gitlab-cicd-environment-variables) can be set in an environment to be available to a runner.
+
+## Deploy Keys
+
+With Deploy Keys, GitLab allows you to import SSH public keys. You can then have
+read only or read/write access to your project from the machines the keys were generated from.
+
+SSH keys added to your project settings will be used for continuous integration,
+staging, or production servers.
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->

doc/ci/quick_start/README.md

@@ -23,7 +23,7 @@ that you can consider for use in your project. You may want to familiarize
 yourself with these prior to getting started.
 GitLab offers a [continuous integration](https://about.gitlab.com/stages-devops-lifecycle/continuous-integration/) service. For each commit or push to trigger your CI
-[pipeline](../pipelines.md), you must:
+[pipeline](../pipelines/index.md), you must:
 - Add a [`.gitlab-ci.yml` file](#creating-a-gitlab-ciyml-file) to your repository's root directory.
 - Ensure your project is configured to use a [Runner](#configuring-a-runner).

doc/ci/runners/README.md

@@ -422,4 +422,4 @@ You can find the IP address of a Runner for a specific project by:
 [register]: https://docs.gitlab.com/runner/register/
 [protected branches]: ../../user/project/protected_branches.md
 [protected tags]: ../../user/project/protected_tags.md
-[project defined timeout]: ../../user/project/pipelines/settings.html#timeout
+[project defined timeout]: ../pipelines/settings.md#timeout

doc/ci/ssh_keys/README.md

@@ -37,7 +37,7 @@ with any type of [executor](https://docs.gitlab.com/runner/executors/)
 NOTE: **Note:**
 The private key will not be displayed in the job log, unless you enable
 [debug logging](../variables/README.md#debug-logging). You might also want to
-check the [visibility of your pipelines](../../user/project/pipelines/settings.md#visibility-of-pipelines).
+check the [visibility of your pipelines](../pipelines/settings.md#visibility-of-pipelines).
 ## SSH keys when using the Docker executor

doc/ci/variables/README.md

@@ -169,7 +169,7 @@ You can either set the variable directly in the `.gitlab-ci.yml`
 file or through the UI.
 NOTE: **Note:**
-It is possible to [specify variables when running manual jobs](../pipelines.md#specifying-variables-when-running-manual-jobs).
+It is possible to [specify variables when running manual jobs](../pipelines/index.md#specifying-variables-when-running-manual-jobs).
 #### Via `.gitlab-ci.yml`
@@ -185,14 +185,19 @@ For a deeper look into them, see [`.gitlab-ci.yml` defined variables](#gitlab-ci
 #### Via the UI
-From the UI, navigate to your project's **Settings > CI/CD** and
-expand **Variables**. Create a new variable by choosing its **type**, naming
-it in the field **Input variable key**, and defining its value in the
-**Input variable value** field:
-![CI/CD settings - new variable](img/new_custom_variables_example.png)
-You'll also see the option to mask and/or protect your variables.
+From within the UI, you can add or update custom environment variables:
+1. Go to your project's **Settings > CI/CD** and expand the **Variables** section.
+1. Click the **Add variable** button. In the **Add variable** modal, fill in the details:
+    - **Key**: Must be one line, with no spaces, using only letters, numbers, `-` or `_`.
+    - **Value**: No limitations.
+    - **Type**: `File` or `Variable`.
+    - **Environment scope**: `All`, or specific environments.
+    - **Protect variable** (Optional): If selected, the variable will only be available in pipelines that run on protected branches or tags.
+    - **Mask variable** (Optional): If selected, the variable's **Value** will be masked in job logs. The variable will fail to save if the value does not meet the [masking requirements](#masked-variables).
+
+After a variable is created, you can update any of the details by clicking on the **{pencil}** **Edit** button.
 Once you've set the variables, call them from the `.gitlab-ci.yml` file:
@@ -460,7 +465,7 @@ limitations with the current Auto DevOps scripting environment.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/44059) in GitLab 10.8.
-[Manually triggered pipelines](../pipelines.md#manually-executing-pipelines) allow you to override the value of a current variable.
+[Manually triggered pipelines](../pipelines/index.md#manually-executing-pipelines) allow you to override the value of a current variable.
 For instance, suppose you added a
 [custom variable `$TEST`](#creating-a-custom-environment-variable)
@@ -616,7 +621,7 @@ variables that were set, etc.
 Before enabling this, you should ensure jobs are visible to
 [team members only](../../user/permissions.md#project-features). You should
-also [erase](../pipelines.md#accessing-individual-jobs) all generated job logs
+also [erase](../pipelines/index.md#accessing-individual-jobs) all generated job logs
 before making them visible again.
 To enable debug logs (traces), set the `CI_DEBUG_TRACE` variable to `true`:

doc/ci/yaml/README.md

@@ -4,7 +4,7 @@ type: reference
 # GitLab CI/CD Pipeline Configuration Reference
-GitLab CI/CD [pipelines](../pipelines.md) are configured using a YAML file called `.gitlab-ci.yml` within each project.
+GitLab CI/CD [pipelines](../pipelines/index.md) are configured using a YAML file called `.gitlab-ci.yml` within each project.
 The `.gitlab-ci.yml` file defines the structure and order of the pipelines and determines:
@@ -2735,7 +2735,7 @@ test:
 ```
 The job-level timeout can exceed the
-[project-level timeout](../../user/project/pipelines/settings.md#timeout) but can not
+[project-level timeout](../pipelines/settings.md#timeout) but can not
 exceed the Runner-specific timeout.
 ### `parallel`
@@ -2906,7 +2906,7 @@ starting, at the cost of reduced parallelization.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/23464) in GitLab 12.3.
 `interruptible` is used to indicate that a job should be canceled if made redundant by a newer pipeline run. Defaults to `false`.
-This value will only be used if the [automatic cancellation of redundant pipelines feature](../../user/project/pipelines/settings.md#auto-cancel-pending-pipelines)
+This value will only be used if the [automatic cancellation of redundant pipelines feature](../pipelines/settings.md#auto-cancel-pending-pipelines)
 is enabled.
 When enabled, a pipeline on the same branch will be canceled when:

doc/development/api_graphql_styleguide.md

@@ -21,6 +21,12 @@ and in [PDF](https://gitlab.com/gitlab-org/create-stage/uploads/8e78ea7f326b2ef6
 Everything covered in this deep dive was accurate as of GitLab 11.9, and while specific
 details may have changed since then, it should still serve as a good introduction.
+## GraphiQL
+
+GraphiQL is an interactive GraphQL API explorer where you can play around with existing queries.
+You can access it in any GitLab environment on `https://<your-gitlab-site.com>/-/graphql-explorer`.
+For example, the one for [GitLab.com](https://gitlab.com/-/graphql-explorer).
+
 ## Authentication
 Authentication happens through the `GraphqlController`, right now this
@@ -335,7 +341,7 @@ field :id, GraphQL::ID_TYPE, description: 'ID of the resource'
 Descriptions of fields and arguments are viewable to users through:
-- The [GraphiQL explorer](../api/graphql/#graphiql).
+- The [GraphiQL explorer](#graphiql).
 - The [static GraphQL API reference](../api/graphql/#reference).
 ### Description styleguide

doc/development/logging.md

@@ -112,20 +112,57 @@ importer progresses. Here's what to do:
    all messages might have `current_user_id` and `project_id` to make it easier
    to search for activities by user for a given time.
-1. Do NOT mix and match types. Elasticsearch won't be able to index your
-   logs properly if you [mix integer and string
-   types](https://www.elastic.co/guide/en/elasticsearch/guide/current/mapping.html#_avoiding_type_gotchas):
-   ```ruby
-   # BAD
-   logger.info(message: "Import error", error: 1)
-   logger.info(message: "Import error", error: "I/O failure")
-   ```
-   ```ruby
-   # GOOD
-   logger.info(message: "Import error", error_code: 1, error: "I/O failure")
-   ```
+#### Implicit schema for JSON logging
+
+When using something like Elasticsearch to index structured logs, there is a
+schema for the types of each log field (even if that schema is implicit /
+inferred). It's important to be consistent with the types of your field values,
+otherwise this might break the ability to search/filter on these fields, or even
+cause whole log events to be dropped. While much of this section is phrased in
+an Elasticsearch-specific way, the concepts should translate to many systems you
+might use to index structured logs. GitLab.com uses Elasticsearch to index log
+data.
+
+Unless a field type is explicitly mapped, Elasticsearch will infer the type from
+the first instance of that field value it sees. Subsequent instances of that
+field value with different types will either fail to be indexed, or in some
+cases (scalar/object conflict), the whole log line will be dropped.
+
+GitLab.com's logging Elasticsearch sets
+[`ignore_malformed`](https://www.elastic.co/guide/en/elasticsearch/reference/current/ignore-malformed.html),
+which allows documents to be indexed even when there are simpler sorts of
+mapping conflict (for example, number / string), although indexing on the affected fields
+will break.
+
+Examples:
+```ruby
+# GOOD
+logger.info(message: "Import error", error_code: 1, error: "I/O failure")
+# BAD
+logger.info(message: "Import error", error: 1)
+logger.info(message: "Import error", error: "I/O failure")
+
+# WORST
+logger.info(message: "Import error", error: "I/O failure")
+logger.info(message: "Import error", error: { message: "I/O failure" })
+```
+
+List elements must be the same type:
+
+```ruby
+# GOOD
+logger.info(a_list: ["foo", "1", "true"])
+
+# BAD
+logger.info(a_list: ["foo", 1, true])
+```
+
+Resources:
+
+- [Elasticsearch mapping - avoiding type gotchas](https://www.elastic.co/guide/en/elasticsearch/guide/current/mapping.html#_avoiding_type_gotchas)
+- [Elasticsearch mapping types]( https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-types.html)
 ## Multi-destination Logging

doc/development/migration_style_guide.md

@@ -176,9 +176,15 @@ Removing a column:
 ```ruby
 include Gitlab::Database::MigrationHelpers
-def change
+def up
   with_lock_retries do
-    remove_column :users, :full_name, :string
+    remove_column :users, :full_name
+  end
+end
+
+def down
+  with_lock_retries do
+    add_column :users, :full_name, :string
   end
 end
 ```
@@ -188,11 +194,17 @@ Removing a foreign key:
 ```ruby
 include Gitlab::Database::MigrationHelpers
-def change
+def up
   with_lock_retries do
     remove_foreign_key :issues, :projects
   end
 end
+
+def down
+  with_lock_retries do
+    add_foreign_key :issues, :projects
+  end
+end
 ```
 Changing default value for a column:
@@ -200,11 +212,17 @@ Changing default value for a column:
 ```ruby
 include Gitlab::Database::MigrationHelpers
-def change
+def up
   with_lock_retries do
     change_column_default :merge_requests, :lock_version, from: nil, to: 0
   end
 end
+
+def down
+  with_lock_retries do
+    change_column_default :merge_requests, :lock_version, from: 0, to: nil
+  end
+end
 ```
 ### When to use the helper method
@@ -231,6 +249,8 @@ Example changes:
 **Note:** `with_lock_retries` method **cannot** be used with `disable_ddl_transaction!`.
+**Note:** `with_lock_retries` method **cannot** be used within the `change` method, you must manually define the `up` and `down` methods to make the migration reversible.
+
 ### How the helper method works
 1. Iterate 50 times.

doc/subscriptions/index.md

@@ -354,7 +354,7 @@ features, and the instance will be read / write again.
 ## CI pipeline minutes
-CI pipeline minutes are the execution time for your [pipelines](../ci/pipelines.md) on GitLab's shared runners. Each [GitLab.com tier](https://about.gitlab.com/pricing/) includes a monthly quota of CI pipeline minutes.
+CI pipeline minutes are the execution time for your [pipelines](../ci/pipelines/index.md) on GitLab's shared runners. Each [GitLab.com tier](https://about.gitlab.com/pricing/) includes a monthly quota of CI pipeline minutes.
 Quotas apply to:

doc/topics/autodevops/index.md

@@ -1375,7 +1375,7 @@ increasing the rollout up to 100%.
 If `INCREMENTAL_ROLLOUT_MODE` is set to `manual` in your project, then instead
 of the standard `production` job, 4 different
-[manual jobs](../../ci/pipelines.md#manual-actions-from-pipeline-graphs)
+[manual jobs](../../ci/pipelines/index.md#manual-actions-from-pipeline-graphs)
 will be created:
 1. `rollout 10%`

doc/user/admin_area/settings/continuous_integration.md

@@ -53,7 +53,7 @@ To change it at the:
   1. Change the value of **maximum artifacts size (in MB)**.
   1. Press **Save changes** for the changes to take effect.
-- [Project level](../../project/pipelines/settings.md) (this will override the instance and group settings):
+- [Project level](../../../ci/pipelines/settings.md) (this will override the instance and group settings):
   1. Go to the project's **Settings > CI / CD > General Pipelines**.
   1. Change the value of **maximum artifacts size (in MB)**.
@@ -152,7 +152,7 @@ Area of your GitLab instance (`.gitlab-ci.yml` if not set):
 1. Input the new path in the **Default CI configuration path** field.
 1. Hit **Save changes** for the changes to take effect.
-It is also possible to specify a [custom CI configuration path for a specific project](../../project/pipelines/settings.md#custom-ci-configuration-path).
+It is also possible to specify a [custom CI configuration path for a specific project](../../../ci/pipelines/settings.md#custom-ci-configuration-path).
 <!-- ## Troubleshooting

doc/user/application_security/configuration/index.md

@@ -13,7 +13,7 @@ features and can be accessed through a project's sidebar nav.
 ![Screenshot of security configuration page](../img/security_configuration_page_v12_9.png)
-The page uses the project's latest default branch [CI pipeline](../../../ci/pipelines.md) to determine the configuration
+The page uses the project's latest default branch [CI pipeline](../../../ci/pipelines/index.md) to determine the configuration
 state of each feature. If a job with the expected security report artifact exists in the pipeline,
 the feature is considered configured.

doc/user/permissions.md

@@ -420,7 +420,7 @@ read through the documentation on the [new CI/CD permissions model](project/new_
 The permission to merge or push to protected branches is used to define if a user can
 run CI/CD pipelines and execute actions on jobs that are related to those branches.
-See [Security on protected branches](../ci/pipelines.md#security-on-protected-branches)
+See [Security on protected branches](../ci/pipelines/index.md#security-on-protected-branches)
 for details about the pipelines security model.
 ## LDAP users permissions

doc/user/project/badges.md

@@ -75,5 +75,5 @@ You can also configure badges via the GitLab API. As in the settings, there is
 a distinction between endpoints for badges on the
 [project level](../../api/project_badges.md) and [group level](../../api/group_badges.md).
-[pipeline status]: pipelines/settings.md#pipeline-status-badge
-[test coverage]: pipelines/settings.md#test-coverage-report-badge
+[pipeline status]: ../../ci/pipelines/settings.md#pipeline-status-badge
+[test coverage]: ../../ci/pipelines/settings.md#test-coverage-report-badge