diff --git a/app/assets/javascripts/nav/components/top_nav_menu_item.vue b/app/assets/javascripts/nav/components/top_nav_menu_item.vue index 07c6fa7773a..bf1fd691ca8 100644 --- a/app/assets/javascripts/nav/components/top_nav_menu_item.vue +++ b/app/assets/javascripts/nav/components/top_nav_menu_item.vue @@ -35,7 +35,7 @@ export default { +import { GlAvatar, GlLink } from '@gitlab/ui'; + +export default { + components: { + GlAvatar, + GlLink, + }, + props: { + runner: { + type: Object, + required: true, + }, + }, + computed: { + groups() { + return this.runner.groups?.nodes || []; + }, + }, +}; + + + diff --git a/app/assets/javascripts/runner/components/runner_details.vue b/app/assets/javascripts/runner/components/runner_details.vue index 56d1109f0f5..81f6fcbb1c2 100644 --- a/app/assets/javascripts/runner/components/runner_details.vue +++ b/app/assets/javascripts/runner/components/runner_details.vue @@ -3,8 +3,9 @@ import { GlTabs, GlTab, GlIntersperse } from '@gitlab/ui'; import { s__ } from '~/locale'; import TimeAgo from '~/vue_shared/components/time_ago_tooltip.vue'; import { timeIntervalInWords } from '~/lib/utils/datetime_utility'; -import { ACCESS_LEVEL_REF_PROTECTED } from '../constants'; +import { ACCESS_LEVEL_REF_PROTECTED, GROUP_TYPE } from '../constants'; import RunnerDetail from './runner_detail.vue'; +import RunnerDetailGroups from './runner_detail_groups.vue'; import RunnerTags from './runner_tags.vue'; export default { @@ -13,6 +14,7 @@ export default { GlTab, GlIntersperse, RunnerDetail, + RunnerDetailGroups, RunnerTags, TimeAgo, }, @@ -43,6 +45,9 @@ export default { } return null; }, + isGroupRunner() { + return this.runner?.runnerType === GROUP_TYPE; + }, }, ACCESS_LEVEL_REF_PROTECTED, }; @@ -53,40 +58,44 @@ export default { -
-
- - - - - - - - - - - - - -
-
+ diff --git a/app/assets/javascripts/runner/graphql/runner_details_shared.fragment.graphql b/app/assets/javascripts/runner/graphql/runner_details_shared.fragment.graphql index 60771af51f4..4479df555b9 100644 --- a/app/assets/javascripts/runner/graphql/runner_details_shared.fragment.graphql +++ b/app/assets/javascripts/runner/graphql/runner_details_shared.fragment.graphql @@ -18,4 +18,13 @@ fragment RunnerDetailsShared on CiRunner { updateRunner deleteRunner } + groups { + nodes { + id + avatarUrl + name + fullName + webUrl + } + } } diff --git a/app/controllers/groups_controller.rb b/app/controllers/groups_controller.rb index 4acbb0482f3..f96e080ecf8 100644 --- a/app/controllers/groups_controller.rb +++ b/app/controllers/groups_controller.rb @@ -38,6 +38,8 @@ class GroupsController < Groups::ApplicationController before_action :check_export_rate_limit!, only: [:export, :download_export] + before_action :track_experiment_event, only: [:new] + helper_method :captcha_required? skip_cross_project_access_check :index, :new, :create, :edit, :update, @@ -378,6 +380,12 @@ class GroupsController < Groups::ApplicationController def captcha_required? captcha_enabled? && !params[:parent_id] end + + def track_experiment_event + return if params[:parent_id] + + experiment(:require_verification_for_namespace_creation, user: current_user).track(:start_create_group) + end end GroupsController.prepend_mod_with('GroupsController') diff --git a/app/experiments/require_verification_for_namespace_creation_experiment.rb b/app/experiments/require_verification_for_namespace_creation_experiment.rb index 1cadac7e7d4..78390ddd099 100644 --- a/app/experiments/require_verification_for_namespace_creation_experiment.rb +++ b/app/experiments/require_verification_for_namespace_creation_experiment.rb @@ -1,6 +1,10 @@ # frozen_string_literal: true class RequireVerificationForNamespaceCreationExperiment < ApplicationExperiment # rubocop:disable Gitlab/NamespacedClass + exclude :existing_user + + EXPERIMENT_START_DATE = Date.new(2022, 1, 31) + def control_behavior false end @@ -24,4 +28,10 @@ class RequireVerificationForNamespaceCreationExperiment < ApplicationExperiment def subject context.value[:user] end + + def existing_user + return false unless user_or_actor + + user_or_actor.created_at < EXPERIMENT_START_DATE + end end diff --git a/app/helpers/groups_helper.rb b/app/helpers/groups_helper.rb index 7296560a450..3fbea0c0472 100644 --- a/app/helpers/groups_helper.rb +++ b/app/helpers/groups_helper.rb @@ -139,7 +139,7 @@ module GroupsHelper {} end - def require_verification_for_group_creation_enabled? + def require_verification_for_namespace_creation_enabled? # overridden in EE false end diff --git a/config/feature_flags/experiment/require_verification_for_group_creation.yml b/config/feature_flags/experiment/require_verification_for_group_creation.yml deleted file mode 100644 index 767d5f55bce..00000000000 --- a/config/feature_flags/experiment/require_verification_for_group_creation.yml +++ /dev/null @@ -1,8 +0,0 @@ ---- -name: require_verification_for_group_creation -introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/77569 -rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/349857 -milestone: '14.7' -type: experiment -group: group::activation -default_enabled: false diff --git a/doc/administration/instance_limits.md b/doc/administration/instance_limits.md index f993784a201..614ab5278c5 100644 --- a/doc/administration/instance_limits.md +++ b/doc/administration/instance_limits.md @@ -214,7 +214,7 @@ or `git push --mirror` is used. This limit does not affect any of the updated merge request pipelines. All updated merge requests have a pipeline created when using -[pipelines for merge requests](../ci/pipelines/merge_request_pipelines.md). +[merge request pipelines](../ci/pipelines/merge_request_pipelines.md). ## Retention of activity history diff --git a/doc/api/merge_requests.md b/doc/api/merge_requests.md index 5189811b539..56682f0f107 100644 --- a/doc/api/merge_requests.md +++ b/doc/api/merge_requests.md @@ -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-pipelines-for-merged-results). **(PREMIUM)** +- 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 diff --git a/doc/ci/environments/index.md b/doc/ci/environments/index.md index 794e4320fc6..9db8774a122 100644 --- a/doc/ci/environments/index.md +++ b/doc/ci/environments/index.md @@ -308,7 +308,7 @@ Note the following: - If the environment URL isn't valid (for example, the URL is malformed), the system doesn't update the environment URL. - If the script that runs in `stop_review` exists only in your repository and therefore can't use - `GIT_STRATEGY: none`, configure [pipelines for merge requests](../../ci/pipelines/merge_request_pipelines.md) + `GIT_STRATEGY: none`, configure [merge request pipelines](../../ci/pipelines/merge_request_pipelines.md) for these jobs. This ensures that runners can fetch the repository even after a feature branch is deleted. For more information, see [Ref Specs for Runners](../pipelines/index.md#ref-specs-for-runners). @@ -440,7 +440,7 @@ the `stop_review` job might not be included in all pipelines that include the The job with [`action: stop` might not run](#the-job-with-action-stop-doesnt-run) if it's in a later stage than the job that started the environment. -If you can't use [pipelines for merge requests](../pipelines/merge_request_pipelines.md), +If you can't use [merge request pipelines](../pipelines/merge_request_pipelines.md), set the [`GIT_STRATEGY`](../runners/configure_runners.md#git-strategy) to `none` in the `stop_review` job. Then the [runner](https://docs.gitlab.com/runner/) doesn't try to check out the code after the branch is deleted. diff --git a/doc/ci/index.md b/doc/ci/index.md index 27122a99d29..d0c2e1986b2 100644 --- a/doc/ci/index.md +++ b/doc/ci/index.md @@ -64,7 +64,7 @@ GitLab CI/CD supports numerous configuration options: | [Git submodules for CI/CD](git_submodules.md) | Configure jobs for using Git submodules. | | [SSH keys for CI/CD](ssh_keys/index.md) | Using SSH keys in your CI pipelines. | | [Pipeline triggers](triggers/index.md) | Trigger pipelines through the API. | -| [Pipelines for merge requests](pipelines/merge_request_pipelines.md) | Design a pipeline structure for running a pipeline in merge requests. | +| [Merge request pipelines](pipelines/merge_request_pipelines.md) | Design a pipeline structure for running a pipeline in merge requests. | | [Integrate with Kubernetes clusters](../user/infrastructure/clusters/index.md) | Connect your project to Google Kubernetes Engine (GKE) or an existing Kubernetes cluster. | | [Optimize GitLab and GitLab Runner for large repositories](large_repositories/index.md) | Recommended strategies for handling large repositories. | | [`.gitlab-ci.yml` full reference](yaml/index.md) | All the attributes you can use with GitLab CI/CD. | diff --git a/doc/ci/jobs/job_control.md b/doc/ci/jobs/job_control.md index a2406a68bb2..051c9935921 100644 --- a/doc/ci/jobs/job_control.md +++ b/doc/ci/jobs/job_control.md @@ -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. | @@ -406,9 +406,9 @@ the `build` job is still skipped. The job does not run for any of the files. With some configurations that use `changes`, [jobs or pipelines might run unexpectedly](#jobs-or-pipelines-run-unexpectedly-when-using-changes) -#### Use `only:changes` with pipelines for merge requests +#### Use `only:changes` with merge request pipelines -With [pipelines for merge requests](../pipelines/merge_request_pipelines.md), +With [merge request pipelines](../pipelines/merge_request_pipelines.md), it's possible to define a job to be created based on files modified in a merge request. @@ -931,7 +931,7 @@ For example: You might have jobs or pipelines that run unexpectedly when using [`rules: changes`](../yaml/index.md#ruleschanges) or [`only: changes`](../yaml/index.md#onlychanges--exceptchanges) without -[pipelines for merge requests](../pipelines/merge_request_pipelines.md). +[merge request pipelines](../pipelines/merge_request_pipelines.md). Pipelines on branches or tags that don't have an explicit association with a merge request use a previous SHA to calculate the diff. This calculation is equivalent to `git diff HEAD~` diff --git a/doc/ci/pipelines/index.md b/doc/ci/pipelines/index.md index 5405c8317cb..6764ebe73ef 100644 --- a/doc/ci/pipelines/index.md +++ b/doc/ci/pipelines/index.md @@ -50,13 +50,13 @@ Pipelines can be configured in many different ways: followed by the next stage. - [Directed Acyclic Graph Pipeline (DAG) pipelines](../directed_acyclic_graph/index.md) are based on relationships between jobs and can run more quickly than basic pipelines. -- [Pipelines for merge requests](../pipelines/merge_request_pipelines.md) run for merge +- [Merge request pipelines](../pipelines/merge_request_pipelines.md) run for merge requests only (rather than for every commit). -- [Pipelines for merged results](../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) - use pipelines for merged results to queue merges one after the other. + use merged results pipelines to queue merges one after the other. - [Parent-child pipelines](parent_child_pipelines.md) break down complex pipelines into one parent pipeline that can trigger multiple child sub-pipelines, which all run in the same project and with the same SHA. This pipeline architecture is commonly used for mono-repos. @@ -123,7 +123,7 @@ This table lists the refspecs injected for each pipeline type: |--------------- |---------------------------------------- | | pipeline for branches | `+:refs/pipelines/` and `+refs/heads/:refs/remotes/origin/` | | pipeline for tags | `+:refs/pipelines/` and `+refs/tags/:refs/tags/` | -| [pipeline for merge requests](../pipelines/merge_request_pipelines.md) | `+:refs/pipelines/` | +| [merge request pipeline](../pipelines/merge_request_pipelines.md) | `+:refs/pipelines/` | The refs `refs/heads/` and `refs/tags/` exist in your project repository. GitLab generates the special ref `refs/pipelines/` during a diff --git a/doc/ci/pipelines/merge_request_pipelines.md b/doc/ci/pipelines/merge_request_pipelines.md index 4d7ebc09e6f..d1788a0f04f 100644 --- a/doc/ci/pipelines/merge_request_pipelines.md +++ b/doc/ci/pipelines/merge_request_pipelines.md @@ -5,13 +5,15 @@ info: To determine the technical writer assigned to the Stage/Group associated w --- -# Pipelines for merge requests **(FREE)** +# 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*. Alternatively, you can configure your pipeline to run every time you make changes to the -source branch for a merge request. This type of pipeline is called a *pipeline for merge requests*. +source branch for a merge request. This type of pipeline is called a *merge request pipeline*. Branch pipelines: @@ -20,28 +22,28 @@ Branch pipelines: - Have access to [some predefined variables](../variables/predefined_variables.md). - Have access to [protected variables](../variables/index.md#protect-a-cicd-variable). -Pipelines for merge requests: +Merge request pipelines: - Run when you: - Create a new merge request. - Push a new commit to the source branch for a merge request. - Select **Run pipeline** from the **Pipelines** tab in a merge request. This option - is only available when pipelines for merge requests are configured for the pipeline. + is only available when merge request pipelines are configured for the pipeline. - Do not run by default. The jobs in the CI/CD configuration file [must be configured](#prerequisites) - to run in pipelines for merge request. + to run in merge request pipelines. - Have access to [more predefined variables](#available-predefined-variables). - Do not have access to [protected variables](../variables/index.md#protect-a-cicd-variable). Both of these types of pipelines can appear on the **Pipelines** tab of a merge request. -## Types of pipelines for merge requests +## Types of merge request pipelines -The three types of pipelines for merge requests are: +The three types of merge request pipelines are: -- Pipelines for merge requests, which run on the changes in the merge request's +- 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. -- [Pipelines for merged results](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 @@ -50,31 +52,31 @@ The three types of pipelines for merge requests are: ## Prerequisites -To use pipelines for merge requests: +To use merge request pipelines: - Your project's [CI/CD configuration file](../yaml/index.md) must be configured with - jobs that run in pipelines for merge requests. To do this, you can use: + jobs that run in merge request pipelines. To do this, you can use: - [`rules`](#use-rules-to-add-jobs). - [`only/except`](#use-only-to-add-jobs). - You must have at least the Developer [role](../../user/permissions.md) in the - source project to run a pipeline for merge requests. + source project to run a merge request pipeline. - Your repository must be a GitLab repository, not an [external repository](../ci_cd_for_external_repos/index.md). ## Use `rules` to add jobs You can use the [`rules`](../yaml/index.md#rules) keyword to configure jobs to run in -pipelines for merge requests. For example: +merge request pipelines. For example: ```yaml job1: script: - - echo "This job runs in pipelines for merge requests" + - echo "This job runs in merge request pipelines" rules: - if: $CI_PIPELINE_SOURCE == 'merge_request_event' ``` You can also use the [`workflow: rules`](../yaml/index.md#workflowrules) keyword -to configure the entire pipeline to run in pipelines for merge requests. For example: +to configure the entire pipeline to run in merge request pipelines. For example: ```yaml workflow: @@ -83,22 +85,22 @@ workflow: job1: script: - - echo "This job runs in pipelines for merge requests" + - echo "This job runs in merge request pipelines" job2: script: - - echo "This job also runs in pipelines for merge requests" + - echo "This job also runs in merge request pipelines" ``` ## Use `only` to add jobs You can use the [`only`](../yaml/index.md#onlyrefs--exceptrefs) keyword with `merge_requests` -to configure jobs to run in pipelines for merge requests. +to configure jobs to run in merge request pipelines. ```yaml job1: script: - - echo "This job runs in pipelines for merge requests" + - echo "This job runs in merge request pipelines" only: - merge_requests ``` @@ -122,7 +124,7 @@ Pipelines for forks display with the **fork** badge in the parent project: ### Run pipelines in the parent project **(PREMIUM)** -Project members in the parent project can choose to run a pipeline for merge requests +Project members in the parent project can choose to run a merge request pipeline for a merge request submitted from a fork project. This pipeline: - Is created and runs in the parent (target) project, not the fork (source) project. @@ -148,12 +150,12 @@ can create pipelines in the parent project for merge requests from a forked proj ## Available predefined variables -When you use pipelines for merge requests, you can use: +When you use merge request pipelines, you can use: - All the same [predefined variables](../variables/predefined_variables.md) that are available in branch pipelines. - [Additional predefined variables](../variables/predefined_variables.md#predefined-variables-for-merge-request-pipelines) - available only to jobs in pipelines for merge requests. These variables contain + available only to jobs in merge request pipelines. These variables contain information from the associated merge request, which can be when calling the [GitLab Merge Request API endpoint](../../api/merge_requests.md) from a job. @@ -166,14 +168,14 @@ to run for both branches and merge requests at the same time. Adjust your pipeli configuration to [avoid duplicate pipelines](../jobs/job_control.md#avoid-duplicate-pipelines). In [GitLab 13.7 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/201845), -you can add `workflow:rules` to [switch from branch pipelines to pipelines for merge requests](../yaml/workflow.md#switch-between-branch-pipelines-and-merge-request-pipelines). +you can add `workflow:rules` to [switch from branch pipelines to merge request pipelines](../yaml/workflow.md#switch-between-branch-pipelines-and-merge-request-pipelines). After a merge request is open on the branch, the pipeline switches to a merge request pipeline. ### Two pipelines when pushing an invalid CI/CD configuration file If you push an invalid CI/CD configuration to a merge request's branch, two failed pipelines appear in the pipelines tab. One pipeline is a failed branch pipeline, -the other is a failed pipeline for merge requests. +the other is a failed merge request pipeline. When the configuration syntax is fixed, no further failed pipelines should appear. To find and fix the configuration problem, you can use: @@ -183,7 +185,7 @@ To find and fix the configuration problem, you can use: ### The merge request's pipeline is marked as failed but the latest pipeline succeeded -It's possible to have both branch pipelines and pipelines for merge requests in the +It's possible to have both branch pipelines and merge request pipelines in the **Pipelines** tab of a single merge request. This might be [by configuration](../yaml/workflow.md#switch-between-branch-pipelines-and-merge-request-pipelines), or [by accident](#two-pipelines-when-pushing-to-a-branch). @@ -191,8 +193,8 @@ 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 pipelines for merge requests are checked, +feature and both pipelines types are present, the merge request pipelines are checked, not the branch pipelines. diff --git a/doc/ci/pipelines/merge_trains.md b/doc/ci/pipelines/merge_trains.md index 9819013dbe3..bb11a6c5297 100644 --- a/doc/ci/pipelines/merge_trains.md +++ b/doc/ci/pipelines/merge_trains.md @@ -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 [pipelines for merged results](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. @@ -93,7 +93,7 @@ In GitLab 13.5 and earlier, there is only one checkbox, named WARNING: If you select the check box but don't configure your CI/CD to use -pipelines for merge requests, your merge requests may become stuck in an +merge request pipelines, your merge requests may become stuck in an unresolved state or your pipelines may be dropped. ## Start a merge train @@ -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,8 +234,8 @@ 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 -[pipelines for merged results](pipelines_for_merged_results.md) are enabled. -To use pipelines for merged results without using merge trains, you can enable a +[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. [GitLab administrators with access to the GitLab Rails console](../../administration/feature_flags.md) diff --git a/doc/ci/pipelines/merged_results_pipelines.md b/doc/ci/pipelines/merged_results_pipelines.md new file mode 100644 index 00000000000..6d2b6473752 --- /dev/null +++ b/doc/ci/pipelines/merged_results_pipelines.md @@ -0,0 +1,78 @@ +--- +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//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. diff --git a/doc/ci/pipelines/pipelines_for_merged_results.md b/doc/ci/pipelines/pipelines_for_merged_results.md index a7f467c65d7..457f5ce9c30 100644 --- a/doc/ci/pipelines/pipelines_for_merged_results.md +++ b/doc/ci/pipelines/pipelines_for_merged_results.md @@ -1,76 +1,9 @@ --- -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' --- -# Pipelines for merged results **(PREMIUM)** +This document was moved to [another location](merged_results_pipelines.md). -A *pipeline for merged results* is a type of [pipeline for merge requests](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. - -Pipelines for merged results 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 [pipeline for merge requests](merge_request_pipelines.md) -and is labeled as `detached`. - -## Prerequisites - -To use pipelines for merged results: - -- Your project's [CI/CD configuration file](../yaml/index.md) must be configured to - [run jobs in pipelines for merge requests](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 pipelines for merged results - -To enable pipelines for merged results 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 -pipelines for merge requests, your merge requests may become stuck in an -unresolved state or your pipelines may be dropped. - -## Troubleshooting - -### Pipelines for merged results are not created - -In GitLab 13.7 and earlier, pipelines for merged results 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 - -Pipelines for merged results run on a merge ref for a merge request -(`refs/merge-requests//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. + + diff --git a/doc/ci/troubleshooting.md b/doc/ci/troubleshooting.md index ad4ef41425d..c72e5a31926 100644 --- a/doc/ci/troubleshooting.md +++ b/doc/ci/troubleshooting.md @@ -69,12 +69,12 @@ if you are using that type: and run separate pipelines in the same project. You can also [dynamically generate the child pipeline's configuration](pipelines/parent_child_pipelines.md#dynamic-child-pipelines) at runtime. -- [Pipelines for merge requests](pipelines/merge_request_pipelines.md): Run a pipeline +- [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): - Pipelines for merge requests that run on the combined source and target branch + - [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 pipelines for merged results that queue and run automatically before + Multiple merged results pipelines that queue and run automatically before changes are merged. ### Troubleshooting Guides for CI/CD features @@ -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, [Pipelines for merged results](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. diff --git a/doc/ci/variables/index.md b/doc/ci/variables/index.md index 7ce58b015ca..87d98382578 100644 --- a/doc/ci/variables/index.md +++ b/doc/ci/variables/index.md @@ -372,7 +372,7 @@ You can protect a project, group or instance CI/CD variable so it is only passed to pipelines running on [protected branches](../../user/project/protected_branches.md) or [protected tags](../../user/project/protected_tags.md). -[Pipelines for merge requests](../pipelines/merge_request_pipelines.md) do not have access to protected variables. +[Merge request pipelines](../pipelines/merge_request_pipelines.md) do not have access to protected variables. An [issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/28002) regarding this limitation. To protect a variable: diff --git a/doc/ci/variables/predefined_variables.md b/doc/ci/variables/predefined_variables.md index 60888cd9b97..2a220908ee1 100644 --- a/doc/ci/variables/predefined_variables.md +++ b/doc/ci/variables/predefined_variables.md @@ -27,7 +27,7 @@ There are also a number of [variables you can use to configure runner behavior]( | `CI_API_V4_URL` | 11.7 | all | The GitLab API v4 root URL. | | `CI_BUILDS_DIR` | all | 11.10 | The top-level directory where builds are executed. | | `CI_COMMIT_AUTHOR` | 13.11 | all | The author of the commit in `Name ` format. | -| `CI_COMMIT_BEFORE_SHA` | 11.2 | all | The previous latest commit present on a branch. Is always `0000000000000000000000000000000000000000` in pipelines for merge requests. | +| `CI_COMMIT_BEFORE_SHA` | 11.2 | all | The previous latest commit present on a branch. Is always `0000000000000000000000000000000000000000` in merge request pipelines. | | `CI_COMMIT_BRANCH` | 12.6 | 0.5 | The commit branch name. Available in branch pipelines, including pipelines for the default branch. Not available in merge request pipelines or tag pipelines. | | `CI_COMMIT_DESCRIPTION` | 10.8 | all | The description of the commit. If the title is shorter than 100 characters, the message without the first line. | | `CI_COMMIT_MESSAGE` | 10.8 | all | The full commit message. | @@ -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. | diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md index d07e30793c2..82562ee588e 100644 --- a/doc/ci/yaml/index.md +++ b/doc/ci/yaml/index.md @@ -415,7 +415,7 @@ and the pipeline is for either: - You can use the [`workflow:rules` templates](workflow.md#workflowrules-templates) to import a preconfigured `workflow: rules` entry. - [Common `if` clauses for `workflow:rules`](workflow.md#common-if-clauses-for-workflowrules). -- [Use `rules` to run pipelines for merge requests](../pipelines/merge_request_pipelines.md#use-rules-to-add-jobs). +- [Use `rules` to run merge request pipelines](../pipelines/merge_request_pipelines.md#use-rules-to-add-jobs). #### `workflow:rules:variables` @@ -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). | @@ -2471,7 +2471,7 @@ Use `changes` in pipelines with the following refs: - `branches` - `external_pull_requests` -- `merge_requests` (see additional details about [using `only:changes` with pipelines for merge requests](../jobs/job_control.md#use-onlychanges-with-pipelines-for-merge-requests)) +- `merge_requests` (see additional details about [using `only:changes` with merge request pipelines](../jobs/job_control.md#use-onlychanges-with-merge-request-pipelines)) **Keyword type**: Job keyword. You can use it only as part of a job. @@ -2513,7 +2513,7 @@ docker build: - [`only: changes` and `except: changes` examples](../jobs/job_control.md#onlychanges--exceptchanges-examples). - If you use `changes` with [only allow merge requests to be merged if the pipeline succeeds](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds), - you should [also use `only:merge_requests`](../jobs/job_control.md#use-onlychanges-with-pipelines-for-merge-requests). + you should [also use `only:merge_requests`](../jobs/job_control.md#use-onlychanges-with-merge-request-pipelines). - [Jobs or pipelines can run unexpectedly when using `only: changes`](../jobs/job_control.md#jobs-or-pipelines-run-unexpectedly-when-using-changes). #### `only:kubernetes` / `except:kubernetes` @@ -3085,7 +3085,7 @@ job: - [Common `if` expressions for `rules`](../jobs/job_control.md#common-if-clauses-for-rules). - [Avoid duplicate pipelines](../jobs/job_control.md#avoid-duplicate-pipelines). -- [Use `rules` to run pipelines for merge requests](../pipelines/merge_request_pipelines.md#use-rules-to-add-jobs). +- [Use `rules` to run merge request pipelines](../pipelines/merge_request_pipelines.md#use-rules-to-add-jobs). #### `rules:changes` diff --git a/doc/ci/yaml/workflow.md b/doc/ci/yaml/workflow.md index 332214638d8..b46d504edfa 100644 --- a/doc/ci/yaml/workflow.md +++ b/doc/ci/yaml/workflow.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 -[pipelines for merged results](../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. @@ -140,7 +140,7 @@ include: The [`MergeRequest-Pipelines` template](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Workflows/MergeRequest-Pipelines.gitlab-ci.yml) makes your pipelines run for the default branch, tags, and all types of merge request pipelines. Use this template if you use any of the -the [pipelines for merge requests features](../pipelines/merge_request_pipelines.md). +the [merge request pipelines features](../pipelines/merge_request_pipelines.md). To [include](index.md#include) it: diff --git a/doc/development/cicd/index.md b/doc/development/cicd/index.md index 17a70393c96..2779b457fb9 100644 --- a/doc/development/cicd/index.md +++ b/doc/development/cicd/index.md @@ -27,7 +27,7 @@ On the left side we have the events that can trigger a pipeline based on various - A `git push` is the most common event that triggers a pipeline. - The [Web API](../../api/pipelines.md#create-a-new-pipeline). - A user clicking the "Run pipeline" button in the UI. -- When a [merge request is created or updated](../../ci/pipelines/merge_request_pipelines.md#pipelines-for-merge-requests). +- When a [merge request is created or updated](../../ci/pipelines/merge_request_pipelines.md). - When an MR is added to a [Merge Train](../../ci/pipelines/merge_trains.md#merge-trains). - A [scheduled pipeline](../../ci/pipelines/schedules.md#pipeline-schedules). - When project is [subscribed to an upstream project](../../ci/pipelines/multi_project_pipelines.md#trigger-a-pipeline-when-an-upstream-project-is-rebuilt). diff --git a/doc/development/code_review.md b/doc/development/code_review.md index 51460dea86d..29228d56848 100644 --- a/doc/development/code_review.md +++ b/doc/development/code_review.md @@ -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: diff --git a/doc/development/documentation/review_apps.md b/doc/development/documentation/review_apps.md index 4b58778a20c..844dc3e72d0 100644 --- a/doc/development/documentation/review_apps.md +++ b/doc/development/documentation/review_apps.md @@ -61,7 +61,7 @@ The following GitLab features are used among others: - [Review Apps](../../ci/review_apps/index.md) - [Artifacts](../../ci/yaml/index.md#artifacts) - [Specific runner](../../ci/runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects) -- [Pipelines for merge requests](../../ci/pipelines/merge_request_pipelines.md) +- [Merge request pipelines](../../ci/pipelines/merge_request_pipelines.md) ## Troubleshooting review apps diff --git a/doc/development/testing_guide/end_to_end/index.md b/doc/development/testing_guide/end_to_end/index.md index 1fc9bc8258a..54287fc0993 100644 --- a/doc/development/testing_guide/end_to_end/index.md +++ b/doc/development/testing_guide/end_to_end/index.md @@ -108,12 +108,12 @@ This problem was discovered in . A feature proposal to segregate access control regarding running pipelines from ability to push/merge was also created at . -#### 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 @@ -126,7 +126,7 @@ A --> C B --> C A --> E["E2E tests"] -C --> D["Pipeline for merged results"] +C --> D["Merged results pipeline"] ``` ##### Running custom tests diff --git a/doc/user/application_security/index.md b/doc/user/application_security/index.md index f5c727a1418..94373346f15 100644 --- a/doc/user/application_security/index.md +++ b/doc/user/application_security/index.md @@ -98,10 +98,10 @@ 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 [pipelines for merge requests](../../ci/pipelines/merge_request_pipelines.md), +To use them with [merge request pipelines](../../ci/pipelines/merge_request_pipelines.md), you may need to override the default `rules:` configuration to add: ```yaml diff --git a/doc/user/project/merge_requests/code_quality.md b/doc/user/project/merge_requests/code_quality.md index d9fa36e4718..d735ce0ef91 100644 --- a/doc/user/project/merge_requests/code_quality.md +++ b/doc/user/project/merge_requests/code_quality.md @@ -248,9 +248,9 @@ This can be done: ### Using with merge request pipelines The configuration provided by the Code Quality template does not let the `code_quality` job -run on [pipelines for merge requests](../../../ci/pipelines/merge_request_pipelines.md). +run on [merge request pipelines](../../../ci/pipelines/merge_request_pipelines.md). -If pipelines for merge requests is enabled, the `code_quality:rules` must be redefined. +If merge request pipelines is enabled, the `code_quality:rules` must be redefined. The template has these [`rules`](../../../ci/yaml/index.md#rules) for the `code quality` job: diff --git a/doc/user/project/merge_requests/drafts.md b/doc/user/project/merge_requests/drafts.md index a91679ffd63..b076b226475 100644 --- a/doc/user/project/merge_requests/drafts.md +++ b/doc/user/project/merge_requests/drafts.md @@ -79,11 +79,11 @@ draft merge requests: ## Pipelines for drafts -When the [pipelines for merged results](../../../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. -To run pipelines for merged results, you must +To run merged results pipelines, you must [mark the merge request as ready](#mark-merge-requests-as-ready).