Automatic merge of gitlab-org/gitlab-ce master

doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md

@@ -64,7 +64,7 @@ Array.methods.grep(/sing/)
 
 ## Find method source
 
-Works for [non-instrumented methods](https://docs.gitlab.com/ce/development/instrumentation.html#checking-instrumented-methods):
+Works for [non-instrumented methods](../../development/instrumentation.md#checking-instrumented-methods):
 
 ```ruby
 instance_of_object.method(:foo).source_location
@@ -474,7 +474,7 @@ User.active.count
 ```
 
 ```bash
-# Using curl and jq (up to a max 100, see [pagination](https://docs.gitlab.com/ee/api/#pagination)
+# Using curl and jq (up to a max 100, see pagination docs https://docs.gitlab.com/ee/api/#pagination
 curl --silent --header "Private-Token: ********************" "https://gitlab.example.com/api/v4/users?per_page=100&active" | jq --compact-output '.[] | [.id,.name,.username]'
 ```
 
@@ -744,7 +744,7 @@ build.dependencies.each do |d| { puts "status: #{d.status}, finished at: #{d.fin
 
 ### Disable strict artifact checking (Introduced in GitLab 10.3.0)
 
-See <https://docs.gitlab.com/ee/administration/job_artifacts.html#validation-for-dependencies>.
+See [job artifacts documentation](../job_artifacts.md#validation-for-dependencies).
 
 ```ruby
 Feature.enable('ci_disable_validates_dependencies')

doc/administration/troubleshooting/kubernetes_cheat_sheet.md

@@ -177,7 +177,7 @@ and they will assist you with any issues you are having.
   ```
 
   After <https://gitlab.com/gitlab-org/charts/gitlab/issues/780> is fixed, it should
-  be possible to use [Updating GitLab using the Helm Chart](https://docs.gitlab.com/ee/install/kubernetes/gitlab_chart.html#updating-gitlab-using-the-helm-chart)
+  be possible to use [Updating GitLab using the Helm Chart](https://docs.gitlab.com/charts/index.html#updating-gitlab-using-the-helm-chart)
   for upgrades.
 
 - How to apply changes to GitLab config:
@@ -244,7 +244,7 @@ to those documents for details.
   on your workstation.
 
 - When all the pods show either a `Running` or `Completed` status, get the GitLab password as
-  described in [Initial login](https://docs.gitlab.com/ee/install/kubernetes/gitlab_chart.html#initial-login),
+  described in [Initial login](https://docs.gitlab.com/charts/installation/deployment.html#initial-login),
   and log in to GitLab via the UI. It will be accessible via `https://gitlab.domain`
   where `domain` is the value provided in the yaml file.
 

doc/administration/troubleshooting/linux_cheat_sheet.md

@@ -259,7 +259,7 @@ then compare summaries of both results and dive into the differences.
 Rough numbers for calls to `open` and `openat` (used to access files) on various configurations.
 Slow storage can cause the dreaded `DeadlineExceeded` error in Gitaly.
 
-Also [see this entry](https://docs.gitlab.com/ee/administration/operations/filesystem_benchmarking.html)
+Also [see this entry](../operations/filesystem_benchmarking.md)
 in the handbook for quick tests customers can perform to check their filesystem performance.
 
 Keep in mind that timing information from `strace` is often somewhat inaccurate, so

doc/administration/troubleshooting/test_environments.md

@@ -23,7 +23,7 @@ but contributions are welcome.
 
 ### GitLab
 
-Please see [our Docker test environment docs](https://docs.gitlab.com/ee/install/digitaloceandocker.html#create-new-gitlab-container)
+Please see [our Docker test environment docs](../../install/digitaloceandocker.md#create-new-gitlab-container)
 for how to run GitLab on Docker. When spinning this up with `docker-machine`, ensure
 you change a few things:
 
@@ -59,7 +59,7 @@ docker run --name gitlab_saml -p 8080:8080 -p 8443:8443 \
 -d jamedjo/test-saml-idp
 ```
 
-The following will also need to go in your `/etc/gitlab/gitlab.rb`. See [our SAML docs](https://docs.gitlab.com/ee/integration/saml.html)
+The following will also need to go in your `/etc/gitlab/gitlab.rb`. See [our SAML docs](../../integration/saml.md)
 for more, as well as the list of [default usernames, passwords, and emails](https://hub.docker.com/r/jamedjo/test-saml-idp/#usage).
 
 ```ruby

doc/ci/docker/using_docker_build.md

@@ -580,7 +580,7 @@ For private and internal projects:
 If you want to use your own Docker images for docker-in-docker there are a few things you need to do in addition to the steps in the [docker-in-docker](#use-docker-in-docker-workflow-with-docker-executor) section:
 
 1. Update the `image` and `service` to point to your registry.
-1. Add a service [alias](https://docs.gitlab.com/ee/ci/yaml/#servicesalias).
+1. Add a service [alias](../yaml/README.md#servicesalias).
 
 Below is an example of what your `.gitlab-ci.yml` should look like,
 assuming you have it configured with [TLS enabled](#tls-enabled):

doc/ci/examples/code_quality.md

 ---
-disqus_identifier: 'https://docs.gitlab.com/ee/ci/examples/code_climate.html'
-type: reference, howto
+redirect_to: '../../user/project/merge_requests/code_quality.md#example-configuration'
 ---
 
-# Analyze your project's Code Quality
-
-CAUTION: **Caution:**
-The job definition shown below is supported on GitLab 11.11 and later versions.
-It also requires the GitLab Runner 11.5 or later.
-For earlier versions, use the [previous job definitions](#previous-job-definitions).
-
-This example shows how to run Code Quality on your code by using GitLab CI/CD
-and Docker.
-
-First, you need GitLab Runner with
-[docker-in-docker executor](../docker/using_docker_build.md#use-docker-in-docker-workflow-with-docker-executor).
-
-Once you set up the Runner, include the CodeQuality template in your CI config:
-
-```yaml
-include:
-  - template: Code-Quality.gitlab-ci.yml
-```
-
-The above example will create a `code_quality` job in your CI/CD pipeline which
-will scan your source code for code quality issues. The report will be saved as a
-[Code Quality report artifact](../yaml/README.md#artifactsreportscodequality-starter)
-that you can later download and analyze.
-Due to implementation limitations we always take the latest Code Quality artifact available.
-
-TIP: **Tip:**
-For [GitLab Starter][ee] users, this information will be automatically
-extracted and shown right in the merge request widget.
-[Learn more on Code Quality in merge requests](../../user/project/merge_requests/code_quality.md).
-
-CAUTION: **Caution:**
-On self-managed instances, if a malicious actor compromises the Code Quality job
-definition they will be able to execute privileged docker commands on the Runner
-host. Having proper access control policies mitigates this attack vector by
-allowing access only to trusted actors.
-
-## Previous job definitions
-
-CAUTION: **Caution:**
-Before GitLab 11.5, Code Quality job and artifact had to be named specifically
-to automatically extract report data and show it in the merge request widget.
-While these old job definitions are still maintained they have been deprecated
-and may be removed in next major release, GitLab 12.0.
-You are advised to update your current `.gitlab-ci.yml` configuration to reflect that change.
-
-For GitLab 11.5 and earlier, the job should look like:
-
-```yaml
-code_quality:
-  image: docker:stable
-  variables:
-    DOCKER_DRIVER: overlay2
-  allow_failure: true
-  services:
-    - docker:stable-dind
-  script:
-    - export SP_VERSION=$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/')
-    - docker run
-        --env SOURCE_CODE="$PWD"
-        --volume "$PWD":/code
-        --volume /var/run/docker.sock:/var/run/docker.sock
-        "registry.gitlab.com/gitlab-org/security-products/codequality:$SP_VERSION" /code
-  artifacts:
-    reports:
-      codequality: gl-code-quality-report.json
-```
-
-For GitLab 11.4 and earlier, the job should look like:
-
-```yaml
-code_quality:
-  image: docker:stable
-  variables:
-    DOCKER_DRIVER: overlay2
-  allow_failure: true
-  services:
-    - docker:stable-dind
-  script:
-    - export SP_VERSION=$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/')
-    - docker run
-        --env SOURCE_CODE="$PWD"
-        --volume "$PWD":/code
-        --volume /var/run/docker.sock:/var/run/docker.sock
-        "registry.gitlab.com/gitlab-org/security-products/codequality:$SP_VERSION" /code
-  artifacts:
-      paths: [gl-code-quality-report.json]
-```
-
-Alternatively the job name could be `codeclimate` or `codequality`
-and the artifact name could be `codeclimate.json`.
-These names have been deprecated with GitLab 11.0
-and may be removed in next major release, GitLab 12.0.
-
-For GitLab 10.3 and earlier, the job should look like:
-
-```yaml
-codequality:
-  image: docker:latest
-  variables:
-    DOCKER_DRIVER: overlay
-  services:
-    - docker:dind
-  script:
-    - docker pull codeclimate/codeclimate:0.69.0
-    - docker run --env CODECLIMATE_CODE="$PWD" --volume "$PWD":/code --volume /var/run/docker.sock:/var/run/docker.sock --volume /tmp/cc:/tmp/cc codeclimate/codeclimate:0.69.0 init
-    - docker run --env CODECLIMATE_CODE="$PWD" --volume "$PWD":/code --volume /var/run/docker.sock:/var/run/docker.sock --volume /tmp/cc:/tmp/cc codeclimate/codeclimate:0.69.0 analyze -f json > codeclimate.json || true
-  artifacts:
-    paths: [codeclimate.json]
-```
-
-[cli]: https://github.com/codeclimate/codeclimate
-[ee]: https://about.gitlab.com/pricing/
+This document was moved to [another location](../../user/project/merge_requests/code_quality.md#example-configuration).

doc/ci/yaml/README.md

@@ -2089,7 +2089,7 @@ staging:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23464) in GitLab 12.3.
 
 `interruptible` is used to indicate that a job should be canceled if made redundant by a newer run of the same job. Defaults to `true`.
-This value will only be used if the [automatic cancellation of redundant pipelines feature](https://docs.gitlab.com/ee/user/project/pipelines/settings.html#auto-cancel-pending-pipelines)
+This value will only be used if the [automatic cancellation of redundant pipelines feature](../../user/project/pipelines/settings.md#auto-cancel-pending-pipelines)
 is enabled.
 
 When enabled, a pipeline on the same branch will be canceled when:

doc/subscriptions/index.md

@@ -115,7 +115,7 @@ To subscribe to GitLab through a self-managed installation:
 
 1. [Install](https://about.gitlab.com/install/) GitLab.
 1. Complete the installation with
-   [administration tasks](https://docs.gitlab.com/ee/administration/).
+   [administration tasks](../administration/index.md).
 1. Select the **Starter**, **Premium**, or **Ultimate** self-managed plan
    through the [GitLab Subscription Manager](https://customers.gitlab.com/).
 1. Apply your license file. After purchase, a license file is sent to the email

doc/user/project/merge_requests/code_quality.md

 ---
 type: reference, howto
-disqus_identifier: 'https://docs.gitlab.com/ee/user/project/merge_requests/code_quality_diff.html'
 ---
 
 # Code Quality **(STARTER)**
@@ -18,7 +17,7 @@ Code Quality:
 - Runs in [pipelines](../../../ci/pipelines.md) using an Docker image built in
   [GitLab Code
   Quality](https://gitlab.com/gitlab-org/security-products/codequality) project.
-- Can make use of a [template](#template-and-examples).
+- Can make use of a [template](#example-configuration).
 - Is available with [Auto
   DevOps](../../../topics/autodevops/index.md#auto-code-quality-starter).
 
@@ -42,14 +41,112 @@ For instance, consider the following workflow:
 1. You approve the merge request and authorize its deployment to staging.
 1. Once verified, their changes are deployed to production.
 
-## Template and examples
+## Example configuration
 
-For most GitLab instances, the supplied template is the preferred method of
-implementing Code Quality. See
-[Analyze your project's Code Quality](../../../ci/examples/code_quality.md) for:
+CAUTION: **Caution:**
+The job definition shown below is supported on GitLab 11.11 and later versions. It
+also requires the GitLab Runner 11.5 or later. For earlier versions, use the
+[previous job definitions](#previous-job-definitions).
 
-- Information on the builtin GitLab Code Quality template.
-- Examples of manual GitLab configuration for earlier GitLab versions.
+This example shows how to run Code Quality on your code by using GitLab CI/CD and Docker.
+
+First, you need GitLab Runner with
+[docker-in-docker executor](../../../ci/docker/using_docker_build.md#use-docker-in-docker-workflow-with-docker-executor).
+
+Once you set up the Runner, include the CodeQuality template in your CI config:
+
+```yaml
+include:
+  - template: Code-Quality.gitlab-ci.yml
+```
+
+The above example will create a `code_quality` job in your CI/CD pipeline which
+will scan your source code for code quality issues. The report will be saved as a
+[Code Quality report artifact](../../../ci/yaml/README.md#artifactsreportscodequality-starter)
+that you can later download and analyze. Due to implementation limitations we always
+take the latest Code Quality artifact available.
+
+TIP: **Tip:**
+This information will be automatically extracted and shown right in the merge request widget.
+
+CAUTION: **Caution:**
+On self-managed instances, if a malicious actor compromises the Code Quality job
+definition they will be able to execute privileged docker commands on the Runner
+host. Having proper access control policies mitigates this attack vector by
+allowing access only to trusted actors.
+
+### Previous job definitions
+
+CAUTION: **Caution:**
+Before GitLab 11.5, Code Quality job and artifact had to be named specifically to
+automatically extract report data and show it in the merge request widget. While these
+old job definitions are still maintained they have been deprecated and may be removed
+in the next major release, GitLab 12.0. You are advised to update your current `.gitlab-ci.yml`
+configuration to reflect that change.
+
+For GitLab 11.5 and earlier, the job should look like:
+
+```yaml
+code_quality:
+  image: docker:stable
+  variables:
+    DOCKER_DRIVER: overlay2
+  allow_failure: true
+  services:
+    - docker:stable-dind
+  script:
+    - export SP_VERSION=$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/')
+    - docker run
+        --env SOURCE_CODE="$PWD"
+        --volume "$PWD":/code
+        --volume /var/run/docker.sock:/var/run/docker.sock
+        "registry.gitlab.com/gitlab-org/security-products/codequality:$SP_VERSION" /code
+  artifacts:
+    reports:
+      codequality: gl-code-quality-report.json
+```
+
+For GitLab 11.4 and earlier, the job should look like:
+
+```yaml
+code_quality:
+  image: docker:stable
+  variables:
+    DOCKER_DRIVER: overlay2
+  allow_failure: true
+  services:
+    - docker:stable-dind
+  script:
+    - export SP_VERSION=$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/')
+    - docker run
+        --env SOURCE_CODE="$PWD"
+        --volume "$PWD":/code
+        --volume /var/run/docker.sock:/var/run/docker.sock
+        "registry.gitlab.com/gitlab-org/security-products/codequality:$SP_VERSION" /code
+  artifacts:
+      paths: [gl-code-quality-report.json]
+```
+
+Alternatively the job name could be `codeclimate` or `codequality` and the artifact
+name could be `codeclimate.json`. These names have been deprecated with GitLab 11.0
+and may be removed in the next major release, GitLab 12.0.
+
+For GitLab 10.3 and earlier, the job should look like:
+
+```yaml
+codequality:
+  image: docker:latest
+  variables:
+    DOCKER_DRIVER: overlay
+  services:
+    - docker:dind
+  script:
+    - docker pull codeclimate/codeclimate:0.69.0
+    - docker run --env CODECLIMATE_CODE="$PWD" --volume "$PWD":/code --volume /var/run/docker.sock:/var/run/docker.sock --volume /tmp/cc:/tmp/cc codeclimate/codeclimate:0.69.0 init
+    - docker run --env CODECLIMATE_CODE="$PWD" --volume "$PWD":/code --volume /var/run/docker.sock:/var/run/docker.sock --volume /tmp/cc:/tmp/cc codeclimate/codeclimate:0.69.0 analyze -f json > codeclimate.json || true
+  artifacts:
+    paths: [codeclimate.json]
+```
 
 ## Configuring jobs using variables