Commit 3736bc11 authored by Kati Paizee's avatar Kati Paizee

Merge branch 'docs-redirect-merged-results-page' into 'master'

Redirect merged results doc page

See merge request gitlab-org/gitlab!79310
parents 30f2a1d8 8f927e26
......@@ -1040,8 +1040,8 @@ It requires `.gitlab-ci.yml` to be configured with `only: [merge_requests]` to c
The new pipeline can be:
- A detached merge request pipeline.
- A [pipeline for merged results](../ci/pipelines/pipelines_for_merged_results.md)
if the [project setting is enabled](../ci/pipelines/pipelines_for_merged_results.md#enable-merged-results-pipelines).
- A [merged results pipeline](../ci/pipelines/merged_results_pipelines.md)
if the [project setting is enabled](../ci/pipelines/merged_results_pipelines.md#enable-merged-results-pipelines).
```plaintext
POST /projects/:id/merge_requests/:merge_request_iid/pipelines
......
......@@ -220,7 +220,7 @@ check the value of the `$CI_PIPELINE_SOURCE` variable:
| `chat` | For pipelines created by using a [GitLab ChatOps](../chatops/index.md) command. |
| `external` | When you use CI services other than GitLab. |
| `external_pull_request_event` | When an external pull request on GitHub is created or updated. See [Pipelines for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests). |
| `merge_request_event` | For pipelines created when a merge request is created or updated. Required to enable [merge request pipelines](../pipelines/merge_request_pipelines.md), [merged results pipelines](../pipelines/pipelines_for_merged_results.md), and [merge trains](../pipelines/merge_trains.md). |
| `merge_request_event` | For pipelines created when a merge request is created or updated. Required to enable [merge request pipelines](../pipelines/merge_request_pipelines.md), [merged results pipelines](../pipelines/merged_results_pipelines.md), and [merge trains](../pipelines/merge_trains.md). |
| `parent_pipeline` | For pipelines triggered by a [parent/child pipeline](../pipelines/parent_child_pipelines.md) with `rules`. Use this pipeline source in the child pipeline configuration so that it can be triggered by the parent pipeline. |
| `pipeline` | For [multi-project pipelines](../pipelines/multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../pipelines/multi_project_pipelines.md#create-multi-project-pipelines-by-using-the-api), or the [`trigger`](../yaml/index.md#trigger) keyword. |
| `push` | For pipelines triggered by a `git push` event, including for branches and tags. |
......
......@@ -52,7 +52,7 @@ Pipelines can be configured in many different ways:
between jobs and can run more quickly than basic pipelines.
- [Merge request pipelines](../pipelines/merge_request_pipelines.md) run for merge
requests only (rather than for every commit).
- [Merged results pipelines](../pipelines/pipelines_for_merged_results.md)
- [Merged results pipelines](../pipelines/merged_results_pipelines.md)
are merge request pipelines that act as though the changes from the source branch have
already been merged into the target branch.
- [Merge trains](../pipelines/merge_trains.md)
......
......@@ -7,6 +7,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Merge request pipelines **(FREE)**
> [Renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/351192) from `pipelines for merge requests` to `merge request pipelines` in GitLab 14.8.
You can configure your [pipeline](index.md) to run every time you commit changes to a branch.
This type of pipeline is called a *branch pipeline*.
......@@ -41,7 +43,7 @@ The three types of merge request pipelines are:
- Merge request pipelines, which run on the changes in the merge request's
source branch. These pipelines display a `detached` label to indicate that the
pipeline ran only on the contents of the source branch, ignoring the target branch.
- [Merged results pipelines](pipelines_for_merged_results.md), which run on
- [Merged results pipelines](merged_results_pipelines.md), which run on
the result of combining the source branch's changes with the target branch.
- [Merge trains](merge_trains.md), which run when merging multiple merge requests
at the same time. The changes from each merge request are combined into the
......@@ -191,7 +193,7 @@ If both types of pipelines are in one merge request, the merge request's pipelin
is not considered successful if:
- The branch pipeline succeeds.
- The pipeline for merge request fails.
- The merge request pipeline fails.
When using the [merge when pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md)
feature and both pipelines types are present, the merge request pipelines are checked,
......
......@@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
For more information about why you might want to use merge trains, read [How merge trains keep your master green](https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-trains/).
When [merged results pipelines](pipelines_for_merged_results.md) are
When [merged results pipelines](merged_results_pipelines.md) are
enabled, the pipeline jobs run as if the changes from your source branch have already
been merged into the target branch.
......@@ -193,8 +193,8 @@ for more information.
### Merge train pipeline cannot be retried
When a pipeline for merge trains fails the merge request is dropped from the train and the pipeline can't be retried.
Pipelines for merge trains run on the merged result of the changes in the merge request and
When a merge train pipeline fails, the merge request is dropped from the train and the pipeline can't be retried.
Merge train pipelines run on the merged result of the changes in the merge request and
the changes from other merge requests already on the train. If the merge request is dropped from the train,
the merged result is out of date and the pipeline can't be retried.
......@@ -211,11 +211,16 @@ is enabled in **Settings > General > Merge requests**. This option requires that
run a new successful pipeline before you can re-add a merge request to a merge train.
Merge trains ensure that each pipeline has succeeded before a merge happens, so
you can clear the **Pipelines must succeed** checkbox and keep
**Enable merge trains and pipelines for merged results** (merge trains) selected.
you can:
- Clear the **Pipelines must succeed** checkbox.
- Select the **Enable merged results pipelines** and **Enable merge trains** checkboxes.
In GitLab 13.5 and earlier, there is only one checkbox, named
**Enable merge trains and pipelines for merged results**.
If you want to keep the **Pipelines must succeed** option selected along with merge
trains, create a new pipeline for merged results when this error occurs:
trains, create a new merged results pipeline when this error occurs:
1. On the **Pipelines** tab, select **Run pipeline**.
1. Select **Start/Add to merge train when pipeline succeeds**.
......@@ -229,7 +234,7 @@ In [GitLab 13.6 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/244831)
you can [enable or disable merge trains in the project settings](#enable-merge-trains).
In GitLab 13.5 and earlier, merge trains are automatically enabled when
[merged results pipelines](pipelines_for_merged_results.md) are enabled.
[merged results pipelines](merged_results_pipelines.md) are enabled.
To use merged results pipelines without using merge trains, you can enable a
[feature flag](../../user/feature_flags.md) that blocks the merge trains feature.
......
---
stage: Verify
group: Pipeline Execution
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Merged results pipelines **(PREMIUM)**
> [Renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/351192) from `pipelines for merged results` to `merged results pipelines` in GitLab 14.8.
A *merged results pipeline* is a type of [merge request pipeline](merge_request_pipelines.md). It is a pipeline that runs against the results of the source and target branches merged together.
GitLab creates an internal commit with the merged results, so the pipeline can run
against it. This commit does not exist in either branch,
but you can view it in the pipeline details.
The pipeline runs against the target branch as it exists at the moment you run the pipeline.
Over time, while you're working in the source branch, the target branch might change.
Any time you want to be sure the merged results are accurate, you should re-run the pipeline.
Merged results pipelines can't run when:
- The target branch has changes that conflict with the changes in the source branch.
- The merge request is a [**Draft** merge request](../../user/project/merge_requests/drafts.md).
In these cases, the pipeline runs as a [merge request pipeline](merge_request_pipelines.md)
and is labeled as `detached`.
## Prerequisites
To use merged results pipelines:
- Your project's [CI/CD configuration file](../yaml/index.md) must be configured to
[run jobs in merge request pipelines](merge_request_pipelines.md#prerequisites).
- Your repository must be a GitLab repository, not an
[external repository](../ci_cd_for_external_repos/index.md).
- You must not be using [fast forward merges](../../user/project/merge_requests/fast_forward_merge.md).
[An issue exits](https://gitlab.com/gitlab-org/gitlab/-/issues/26996) to change this behavior.
## Enable merged results pipelines
To enable merged results pipelines in a project, you must have at least the
[Maintainer role](../../user/permissions.md):
1. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Settings > General**.
1. Expand **Merge requests**.
1. Select **Enable merged results pipelines**.
1. Select **Save changes**.
WARNING:
If you select the checkbox but don't configure your pipeline to use
merge request pipelines, your merge requests may become stuck in an
unresolved state or your pipelines may be dropped.
## Troubleshooting
### Merged results pipelines are not created
In GitLab 13.7 and earlier, merged results pipelines might not be created due
to a disabled [feature flag](../../user/feature_flags.md). This feature flag
[was removed](https://gitlab.com/gitlab-org/gitlab/-/issues/299115) in GitLab 13.8.
Upgrade to 13.8 or later, or make sure the `:merge_ref_auto_sync`
[feature flag is enabled](../../administration/feature_flags.md#check-if-a-feature-flag-is-enabled)
on your GitLab instance.
### Pipelines fail intermittently with a `fatal: reference is not a tree:` error
Merged results pipelines run on a merge ref for a merge request
(`refs/merge-requests/<iid>/merge`), so the Git reference could be overwritten at an
unexpected time.
For example, when a source or target branch is advanced, the pipeline fails with
the `fatal: reference is not a tree:` error, which indicates that the checkout-SHA
is not found in the merge ref.
This behavior was improved in GitLab 12.4 by introducing [persistent pipeline refs](../troubleshooting.md#fatal-reference-is-not-a-tree-error).
Upgrade to GitLab 12.4 or later to resolve the problem.
---
stage: Verify
group: Pipeline Execution
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
redirect_to: 'merged_results_pipelines.md'
remove_date: '2022-04-27'
---
# Merged results pipelines **(PREMIUM)**
This document was moved to [another location](merged_results_pipelines.md).
A *pipeline for merged results* is a type of [merge request pipeline](merge_request_pipelines.md). It is a pipeline that runs against the results of the source and target branches merged together.
GitLab creates an internal commit with the merged results, so the pipeline can run
against it. This commit does not exist in either branch,
but you can view it in the pipeline details.
The pipeline runs against the target branch as it exists at the moment you run the pipeline.
Over time, while you're working in the source branch, the target branch might change.
Any time you want to be sure the merged results are accurate, you should re-run the pipeline.
Merged results pipelines can't run when:
- The target branch has changes that conflict with the changes in the source branch.
- The merge request is a [**Draft** merge request](../../user/project/merge_requests/drafts.md).
In these cases, the pipeline runs as a [merge request pipeline](merge_request_pipelines.md)
and is labeled as `detached`.
## Prerequisites
To use merged results pipelines:
- Your project's [CI/CD configuration file](../yaml/index.md) must be configured to
[run jobs in merge request pipelines](merge_request_pipelines.md#prerequisites).
- Your repository must be a GitLab repository, not an
[external repository](../ci_cd_for_external_repos/index.md).
- You must not be using [fast forward merges](../../user/project/merge_requests/fast_forward_merge.md).
[An issue exits](https://gitlab.com/gitlab-org/gitlab/-/issues/26996) to change this behavior.
## Enable merged results pipelines
To enable merged results pipelines in a project, you must have at least the
[Maintainer role](../../user/permissions.md):
1. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Settings > General**.
1. Expand **Merge requests**.
1. Select **Enable merged results pipelines**.
1. Select **Save changes**.
WARNING:
If you select the checkbox but don't configure your pipeline to use
merge request pipelines, your merge requests may become stuck in an
unresolved state or your pipelines may be dropped.
## Troubleshooting
### Merged results pipelines are not created
In GitLab 13.7 and earlier, merged results pipelines might not be created due
to a disabled [feature flag](../../user/feature_flags.md). This feature flag
[was removed](https://gitlab.com/gitlab-org/gitlab/-/issues/299115) in GitLab 13.8.
Upgrade to 13.8 or later, or make sure the `:merge_ref_auto_sync`
[feature flag is enabled](../../administration/feature_flags.md#check-if-a-feature-flag-is-enabled)
on your GitLab instance.
### Pipelines fail intermittently with a `fatal: reference is not a tree:` error
Merged results pipelines run on a merge ref for a merge request
(`refs/merge-requests/<iid>/merge`), so the Git reference could be overwritten at an
unexpected time.
For example, when a source or target branch is advanced, the pipeline fails with
the `fatal: reference is not a tree:` error, which indicates that the checkout-SHA
is not found in the merge ref.
This behavior was improved in GitLab 12.4 by introducing [persistent pipeline refs](../troubleshooting.md#fatal-reference-is-not-a-tree-error).
Upgrade to GitLab 12.4 or later to resolve the problem.
<!-- This redirect file can be deleted after 2022-04-27. -->
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
......@@ -71,7 +71,7 @@ if you are using that type:
at runtime.
- [Merge request pipelines](pipelines/merge_request_pipelines.md): Run a pipeline
in the context of a merge request.
- [Pipelines for merge results](pipelines/pipelines_for_merged_results.md):
- [Merged results pipelines](pipelines/merged_results_pipelines.md):
Merge request pipelines that run on the combined source and target branch
- [Merge trains](pipelines/merge_trains.md):
Multiple merged results pipelines that queue and run automatically before
......@@ -173,8 +173,8 @@ a branch to its remote repository. To illustrate the problem, suppose you've had
This occurs because the previous pipeline cannot find a checkout-SHA (which is associated with the pipeline record)
from the `example` branch that the commit history has already been overwritten by the force-push.
Similarly, [Merged results pipelines](pipelines/pipelines_for_merged_results.md)
might have failed intermittently due to [the same reason](pipelines/pipelines_for_merged_results.md#pipelines-fail-intermittently-with-a-fatal-reference-is-not-a-tree-error).
Similarly, [Merged results pipelines](pipelines/merged_results_pipelines.md)
might have failed intermittently due to [the same reason](pipelines/merged_results_pipelines.md#pipelines-fail-intermittently-with-a-fatal-reference-is-not-a-tree-error).
As of GitLab 12.4, we've improved this behavior by persisting pipeline refs exclusively.
To illustrate its life cycle:
......@@ -229,7 +229,7 @@ should disable **Pipelines must succeed** so you can accept merge requests.
### "The pipeline for this merge request did not complete. Push a new commit to fix the failure or check the troubleshooting documentation to see other possible actions." message
This message is shown if the [merge request pipeline](pipelines/merge_request_pipelines.md),
[merged results pipeline](pipelines/pipelines_for_merged_results.md),
[merged results pipeline](pipelines/merged_results_pipelines.md),
or [merge train pipeline](pipelines/merge_trains.md)
has failed or been canceled.
......
......@@ -148,12 +148,12 @@ These variables are available when:
| `CI_MERGE_REQUEST_PROJECT_URL` | 11.6 | all | The URL of the project of the merge request. For example, `http://192.168.10.15:3000/namespace/awesome-project`. |
| `CI_MERGE_REQUEST_REF_PATH` | 11.6 | all | The ref path of the merge request. For example, `refs/merge-requests/1/head`. |
| `CI_MERGE_REQUEST_SOURCE_BRANCH_NAME` | 11.6 | all | The source branch name of the merge request. |
| `CI_MERGE_REQUEST_SOURCE_BRANCH_SHA` | 11.9 | all | The HEAD SHA of the source branch of the merge request. The variable is empty in merge request pipelines. The SHA is present only in [merged results pipelines](../pipelines/pipelines_for_merged_results.md). **(PREMIUM)** |
| `CI_MERGE_REQUEST_SOURCE_BRANCH_SHA` | 11.9 | all | The HEAD SHA of the source branch of the merge request. The variable is empty in merge request pipelines. The SHA is present only in [merged results pipelines](../pipelines/merged_results_pipelines.md). |
| `CI_MERGE_REQUEST_SOURCE_PROJECT_ID` | 11.6 | all | The ID of the source project of the merge request. |
| `CI_MERGE_REQUEST_SOURCE_PROJECT_PATH` | 11.6 | all | The path of the source project of the merge request. |
| `CI_MERGE_REQUEST_SOURCE_PROJECT_URL` | 11.6 | all | The URL of the source project of the merge request. |
| `CI_MERGE_REQUEST_TARGET_BRANCH_NAME` | 11.6 | all | The target branch name of the merge request. |
| `CI_MERGE_REQUEST_TARGET_BRANCH_SHA` | 11.9 | all | The HEAD SHA of the target branch of the merge request. The variable is empty in merge request pipelines. The SHA is present only in [merged results pipelines](../pipelines/pipelines_for_merged_results.md). **(PREMIUM)** |
| `CI_MERGE_REQUEST_TARGET_BRANCH_SHA` | 11.9 | all | The HEAD SHA of the target branch of the merge request. The variable is empty in merge request pipelines. The SHA is present only in [merged results pipelines](../pipelines/merged_results_pipelines.md). |
| `CI_MERGE_REQUEST_TITLE` | 11.9 | all | The title of the merge request. |
| `CI_MERGE_REQUEST_EVENT_TYPE` | 12.3 | all | The event type of the merge request. Can be `detached`, `merged_result` or `merge_train`. |
| `CI_MERGE_REQUEST_DIFF_ID` | 13.7 | all | The version of the merge request diff. |
......
......@@ -2372,7 +2372,7 @@ pipeline based on branch names or pipeline types.
| `chat` | For pipelines created by using a [GitLab ChatOps](../chatops/index.md) command. |
| `external` | When you use CI services other than GitLab. |
| `external_pull_requests` | When an external pull request on GitHub is created or updated (See [Pipelines for external pull requests](../ci_cd_for_external_repos/index.md#pipelines-for-external-pull-requests)). |
| `merge_requests` | For pipelines created when a merge request is created or updated. Enables [merge request pipelines](../pipelines/merge_request_pipelines.md), [merged results pipelines](../pipelines/pipelines_for_merged_results.md), and [merge trains](../pipelines/merge_trains.md). |
| `merge_requests` | For pipelines created when a merge request is created or updated. Enables [merge request pipelines](../pipelines/merge_request_pipelines.md), [merged results pipelines](../pipelines/merged_results_pipelines.md), and [merge trains](../pipelines/merge_trains.md). |
| `pipelines` | For [multi-project pipelines](../pipelines/multi_project_pipelines.md) created by [using the API with `CI_JOB_TOKEN`](../pipelines/multi_project_pipelines.md#create-multi-project-pipelines-by-using-the-api), or the [`trigger`](#trigger) keyword. |
| `pushes` | For pipelines triggered by a `git push` event, including for branches and tags. |
| `schedules` | For [scheduled pipelines](../pipelines/schedules.md). |
......
......@@ -126,7 +126,7 @@ makes your pipelines run for branches and tags.
Branch pipeline status is displayed in merge requests that use the branch
as a source. However, this pipeline type does not support any features offered by
[merge request pipelines](../pipelines/merge_request_pipelines.md), like
[merged results pipelines](../pipelines/pipelines_for_merged_results.md)
[merged results pipelines](../pipelines/merged_results_pipelines.md)
or [merge trains](../pipelines/merge_trains.md).
This template intentionally avoids those features.
......
......@@ -479,7 +479,7 @@ WARNING:
[very specific cases](https://about.gitlab.com/handbook/engineering/workflow/#criteria-for-merging-during-broken-master).
For other cases, follow these [handbook instructions](https://about.gitlab.com/handbook/engineering/workflow/#merging-during-broken-master).
- If the latest pipeline was created before the merge request was approved, start a new pipeline to ensure that full RSpec suite has been run. You may skip this step only if the merge request does not contain any backend change.
- If the **latest [Pipeline for Merged Results](../ci/pipelines/pipelines_for_merged_results.md)** finished less than 2 hours ago, you
- If the **latest [merged results pipeline](../ci/pipelines/merged_results_pipelines.md)** finished less than 2 hours ago, you
may merge without starting a new pipeline as the merge request is close
enough to `main`.
- When you set the MR to "Merge When Pipeline Succeeds", you should take over
......@@ -489,7 +489,7 @@ WARNING:
the squashed commit's default commit message is taken from the merge request title.
You're encouraged to [select a commit with a more informative commit message](../user/project/merge_requests/squash_and_merge.md) before merging.
Thanks to **Pipeline for Merged Results**, authors no longer have to rebase their
Thanks to **merged results pipelines**, authors no longer have to rebase their
branch as frequently anymore (only when there are conflicts) because the Merge
Results Pipeline already incorporate the latest changes from `main`.
This results in faster review/merge cycles because maintainers don't have to ask
......@@ -501,7 +501,7 @@ Merge Results against the latest `main` at the time of the pipeline creation.
WARNING:
**Review all changes thoroughly for malicious code before starting a
[Pipeline for Merged Results](../ci/pipelines/merge_request_pipelines.md#run-pipelines-in-the-parent-project).**
[merged results pipeline](../ci/pipelines/merge_request_pipelines.md#run-pipelines-in-the-parent-project).**
When reviewing merge requests added by wider community contributors:
......
......@@ -108,12 +108,12 @@ This problem was discovered in <https://gitlab.com/gitlab-org/gitlab-qa/-/issues
work-around was suggested in <https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/4717>.
A feature proposal to segregate access control regarding running pipelines from ability to push/merge was also created at <https://gitlab.com/gitlab-org/gitlab/-/issues/24585>.
#### With Pipeline for Merged Results
#### With merged results pipelines
In a Pipeline for Merged Results, the pipeline runs on a new ref that contains the merge result of the source and target branch.
In a merged results pipeline, the pipeline runs on a new ref that contains the merge result of the source and target branch.
However, this ref is not available to the `gitlab-qa-mirror` pipeline.
For this reason, the end-to-end tests on a Pipeline for Merged Results would use the head of the merge request source branch.
For this reason, the end-to-end tests on a merged results pipeline would use the head of the merge request source branch.
```mermaid
graph LR
......
......@@ -98,7 +98,7 @@ base address for Docker images. You can override this globally by setting the CI
the container-scanning analyzer which uses
`registry.gitlab.com/security-products/container-scanning` as its registry.
### Use security scanning tools with Pipelines for Merge Requests
### Use security scanning tools with merge request pipelines
By default, the application security jobs are configured to run for branch pipelines only.
To use them with [merge request pipelines](../../ci/pipelines/merge_request_pipelines.md),
......
......@@ -79,7 +79,7 @@ draft merge requests:
## Pipelines for drafts
When the [merged results pipelines](../../../ci/pipelines/pipelines_for_merged_results.md)
When the [merged results pipelines](../../../ci/pipelines/merged_results_pipelines.md)
feature is enabled, draft merge requests run
[merge request pipelines](../../../ci/pipelines/merge_request_pipelines.md) only.
......
......@@ -43,7 +43,7 @@ This template requires:
- CI/CD configured to:
- Use a Docker image with Ruby available.
- Use [Merge request pipelines](../../../ci/pipelines/merge_request_pipelines.md#prerequisites)
- [Pipelines for Merged Results](../../../ci/pipelines/pipelines_for_merged_results.md#enable-merged-results-pipelines)
- [Merged results pipelines](../../../ci/pipelines/merged_results_pipelines.md#enable-merged-results-pipelines)
enabled in the project settings.
- A Docker image with Ruby available. The template uses `image: ruby:2.6` by default, but you [can override](../../../ci/yaml/includes.md#override-included-configuration-values) this.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment