...@@ -48,7 +48,7 @@ There are some high level differences between the products worth mentioning: ...@@ -48,7 +48,7 @@ There are some high level differences between the products worth mentioning:
- on push - on push
- on [schedule](../pipelines/schedules.md) - 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 [API call](../triggers/README.md)
- by [webhook](../triggers/README.md#triggering-a-pipeline-from-a-webhook) - by [webhook](../triggers/README.md#triggering-a-pipeline-from-a-webhook)
- by [ChatOps](../chatops/README.md) - by [ChatOps](../chatops/README.md)
...@@ -83,6 +83,29 @@ There are some high level differences between the products worth mentioning: ...@@ -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). 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. - 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 ## Groovy vs. YAML
Jenkins Pipelines are based on [Groovy](https://groovy-lang.org/), so the pipeline specification is written as code. Jenkins Pipelines are based on [Groovy](https://groovy-lang.org/), so the pipeline specification is written as code.
... ...
......
...@@ -9,7 +9,7 @@ Requires GitLab Runner 11.2 and above. ...@@ -9,7 +9,7 @@ Requires GitLab Runner 11.2 and above.
## Overview ## 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. test job that will verify your code.
If the tests fail, the pipeline fails and users get notified. The person that 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 works on the merge request will have to check the job logs and see where the
...@@ -42,13 +42,15 @@ JUnit test reports, where: ...@@ -42,13 +42,15 @@ JUnit test reports, where:
- The base branch is the target branch (usually `master`). - The base branch is the target branch (usually `master`).
- The head branch is the source branch (the latest pipeline in each merge request). - 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. The reports panel has a summary showing how many tests failed, how many had errors
If no comparison can be done because data for the base branch is not available, and how many were fixed. If no comparison can be done because data for the base branch
the panel will just show the list of failed tests for head. is not available, the panel will just show the list of failed tests for head.
There are three types of results: There are four types of results:
1. **Newly failed tests:** Test cases which passed on base branch and failed on head branch 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. **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 1. **Resolved failures:** Test cases which failed on base branch and passed on head branch
... ...
......
...@@ -115,7 +115,7 @@ unexpected timing. For example, when a source or target branch is advanced. ...@@ -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, 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. 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. You should be able to create pipelines at any timings without concerning the error.
## Using Merge Trains **(PREMIUM)** ## Using Merge Trains **(PREMIUM)**
... ...
......
...@@ -40,7 +40,7 @@ With Multi-Project Pipelines you can visualize the entire pipeline, including al ...@@ -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). > [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 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) ![Multi-project pipeline graph](img/multi_project_pipeline_graph.png)
... ...
......
This diff is collapsed.
File moved
File moved
File moved
File moved
File moved
File moved
File moved
File moved
File moved
File moved
File moved
File moved
File moved
File moved
File moved