Add latest changes from gitlab-org/gitlab@master

doc/ci/jenkins/index.md

@@ -48,7 +48,7 @@ There are some high level differences between the products worth mentioning:
   - on push
   - on [schedule](../pipelines/schedules.md)
-  - from the [GitLab UI](../pipelines.md#manually-executing-pipelines)
+  - from the [GitLab UI](../pipelines/index.md#manually-executing-pipelines)
   - by [API call](../triggers/README.md)
   - by [webhook](../triggers/README.md#triggering-a-pipeline-from-a-webhook)
   - by [ChatOps](../chatops/README.md)
@@ -83,6 +83,29 @@ There are some high level differences between the products worth mentioning:
   own environment, which will be slower and may be less consistent. We have extensive docs on [how to use the Container Registry](../../user/packages/container_registry/index.md).
 - Totally stuck and not sure where to turn for advice? The [GitLab community forum](https://forum.gitlab.com/) can be a great resource.
+## Agents vs. Runners
+
+Both Jenkins agents and GitLab Runners are the hosts that run jobs. To convert the
+Jenkins agent, simply uninstall it and then [install and register the runner](../runners/README.md).
+Runners do not require much overhead, so you can size them similarly to the Jenkins
+agents you were using.
+
+There are some important differences in the way Runners work in comparison to agents:
+
+- Runners can be set up as [shared across an instance, be added at the group level, or set up at the project level](../runners/README.md#shared-specific-and-group-runners).
+  They will self-select jobs from the scopes you've defined automatically.
+- You can also [use tags](../runners/README.md#using-tags) for finer control, and
+  associate runners with specific jobs. For example, you can use a tag for jobs that
+  require dedicated, more powerful, or specific hardware.
+- GitLab has [autoscaling for Runners](https://docs.gitlab.com/runner/configuration/autoscale.html)
+  which will let configure them to be provisioned as needed, and scaled down when not.
+  This is similar to ephemeral agents in Jenkins.
+
+If you are using `gitlab.com`, you can take advantage of our [shared Runner fleet](../../user/gitlab_com/index.md#shared-runners)
+to run jobs without provisioning your own Runners. We are investigating making them
+[available for self-managed instances](https://gitlab.com/gitlab-org/customers-gitlab-com/issues/414)
+as well.
+
 ## Groovy vs. YAML
 Jenkins Pipelines are based on [Groovy](https://groovy-lang.org/), so the pipeline specification is written as code.

doc/ci/junit_test_reports.md

@@ -9,7 +9,7 @@ Requires GitLab Runner 11.2 and above.
 ## Overview
-It is very common that a [CI/CD pipeline](pipelines.md) contains a
+It is very common that a [CI/CD pipeline](pipelines/index.md) contains a
 test job that will verify your code.
 If the tests fail, the pipeline fails and users get notified. The person that
 works on the merge request will have to check the job logs and see where the
@@ -42,13 +42,15 @@ JUnit test reports, where:
 - The base branch is the target branch (usually `master`).
 - The head branch is the source branch (the latest pipeline in each merge request).
-The reports panel has a summary showing how many tests failed and how many were fixed.
-If no comparison can be done because data for the base branch is not available,
-the panel will just show the list of failed tests for head.
-There are three types of results:
+The reports panel has a summary showing how many tests failed, how many had errors
+and how many were fixed. If no comparison can be done because data for the base branch
+is not available, the panel will just show the list of failed tests for head.
+There are four types of results:
 1. **Newly failed tests:** Test cases which passed on base branch and failed on head branch
+1. **Newly encountered errors:** Test cases which passed on base branch and failed due to a
+   test error on head branch
 1. **Existing failures:**  Test cases which failed on base branch and failed on head branch
 1. **Resolved failures:**  Test cases which failed on base branch and passed on head branch

doc/ci/merge_request_pipelines/pipelines_for_merged_results/index.md

@@ -115,7 +115,7 @@ unexpected timing. For example, when a source or target branch is advanced.
 In this case, the pipeline fails because of `fatal: reference is not a tree:` error,
 which indicates that the checkout-SHA is not found in the merge ref.
-This behavior was improved at GitLab 12.4 by introducing [Persistent pipeline refs](../../pipelines.md#persistent-pipeline-refs).
+This behavior was improved at GitLab 12.4 by introducing [Persistent pipeline refs](../../pipelines/index.md#persistent-pipeline-refs).
 You should be able to create pipelines at any timings without concerning the error.
 ## Using Merge Trains **(PREMIUM)**

doc/ci/multi_project_pipelines.md

@@ -40,7 +40,7 @@ With Multi-Project Pipelines you can visualize the entire pipeline, including al
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/2121) in [GitLab Premium 9.3](https://about.gitlab.com/releases/2017/06/22/gitlab-9-3-released/#multi-project-pipeline-graphs).
 When you configure GitLab CI for your project, you can visualize the stages of your
-[jobs](pipelines.md#configuring-pipelines) on a [pipeline graph](pipelines.md#visualizing-pipelines).
+[jobs](pipelines/index.md#configuring-pipelines) on a [pipeline graph](pipelines/index.md#visualizing-pipelines).
 ![Multi-project pipeline graph](img/multi_project_pipeline_graph.png)