Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
1527ce5101
commit
59419b9e3e
|
|
@ -57,7 +57,11 @@ release-environments-notification-start:
|
|||
|
||||
release-environments-deploy:
|
||||
stage: deploy
|
||||
extends: .inherit_variables
|
||||
inherit:
|
||||
variables: false
|
||||
variables:
|
||||
VERSIONS: "${VERSIONS}"
|
||||
ENVIRONMENT: "${ENVIRONMENT}"
|
||||
trigger:
|
||||
project: gitlab-com/gl-infra/release-environments
|
||||
branch: main
|
||||
|
|
|
|||
|
|
@ -15,19 +15,4 @@ Style/RedundantInterpolation:
|
|||
- 'lib/gitlab/repository_cache.rb'
|
||||
- 'lib/gitlab/repository_cache_adapter.rb'
|
||||
- 'lib/gitlab/repository_hash_cache.rb'
|
||||
- 'lib/gitlab/repository_set_cache.rb'
|
||||
- 'lib/gitlab/usage_data_counters/search_counter.rb'
|
||||
- 'lib/kramdown/converter/commonmark.rb'
|
||||
- 'lib/tasks/gettext.rake'
|
||||
- 'lib/tasks/gitlab/seed/group_seed.rake'
|
||||
- 'qa/qa/ee/page/component/secure_report.rb'
|
||||
- 'qa/qa/ee/page/project/issue/show.rb'
|
||||
- 'qa/qa/ee/page/project/secure/vulnerability_details.rb'
|
||||
- 'qa/qa/resource/events/base.rb'
|
||||
- 'qa/qa/service/praefect_manager.rb'
|
||||
- 'qa/qa/specs/features/browser_ui/4_verify/pipeline/include_multiple_files_from_a_project_spec.rb'
|
||||
- 'qa/qa/specs/features/ee/browser_ui/3_create/repository/project_templates_spec.rb'
|
||||
- 'qa/qa/specs/features/ee/browser_ui/4_verify/parent_child_pipelines_dependent_relationship_spec.rb'
|
||||
- 'qa/qa/tools/generate_perf_testdata.rb'
|
||||
- 'scripts/perf/gc/print_gc_stats.rb'
|
||||
- 'scripts/qa/testcases-check'
|
||||
|
||||
|
|
|
|||
2
Gemfile
2
Gemfile
|
|
@ -555,7 +555,7 @@ group :test do
|
|||
# Moved in `test` because https://gitlab.com/gitlab-org/gitlab/-/issues/217527
|
||||
gem 'derailed_benchmarks', require: false # rubocop:todo Gemfile/MissingFeatureCategory
|
||||
|
||||
gem 'gitlab_quality-test_tooling', '~> 1.23.0', require: false, feature_category: :tooling
|
||||
gem 'gitlab_quality-test_tooling', '~> 1.24.0', require: false, feature_category: :tooling
|
||||
end
|
||||
|
||||
gem 'octokit', '~> 8.1', feature_category: :importers
|
||||
|
|
|
|||
|
|
@ -228,7 +228,7 @@
|
|||
{"name":"gitlab-styles","version":"11.0.0","platform":"ruby","checksum":"0dd8ec066ce9955ac51d3616c6bfded30f75bb526f39ff392ece6f43d5b9406b"},
|
||||
{"name":"gitlab_chronic_duration","version":"0.12.0","platform":"ruby","checksum":"0d766944d415b5c831f176871ee8625783fc0c5bfbef2d79a3a616f207ffc16d"},
|
||||
{"name":"gitlab_omniauth-ldap","version":"2.2.0","platform":"ruby","checksum":"bb4d20acb3b123ed654a8f6a47d3fac673ece7ed0b6992edb92dca14bad2838c"},
|
||||
{"name":"gitlab_quality-test_tooling","version":"1.23.0","platform":"ruby","checksum":"96af4e12d8b253d29b24a961a10e2a472c459fb24fa06a5ed97cb5ae4ffdec5d"},
|
||||
{"name":"gitlab_quality-test_tooling","version":"1.24.0","platform":"ruby","checksum":"52b8f536943818a633ba9b86fb4a4308ec92013f30007f0371b474e217032fa3"},
|
||||
{"name":"globalid","version":"1.1.0","platform":"ruby","checksum":"b337e1746f0c8cb0a6c918234b03a1ddeb4966206ce288fbb57779f59b2d154f"},
|
||||
{"name":"gon","version":"6.4.0","platform":"ruby","checksum":"e3a618d659392890f1aa7db420f17c75fd7d35aeb5f8fe003697d02c4b88d2f0"},
|
||||
{"name":"google-apis-androidpublisher_v3","version":"0.34.0","platform":"ruby","checksum":"d7e1d7dd92f79c498fe2082222a1740d788e022e660c135564b3fd299cab5425"},
|
||||
|
|
|
|||
|
|
@ -737,7 +737,7 @@ GEM
|
|||
omniauth (>= 1.3, < 3)
|
||||
pyu-ruby-sasl (>= 0.0.3.3, < 0.1)
|
||||
rubyntlm (~> 0.5)
|
||||
gitlab_quality-test_tooling (1.23.0)
|
||||
gitlab_quality-test_tooling (1.24.0)
|
||||
activesupport (>= 6.1, < 7.2)
|
||||
amatch (~> 0.4.1)
|
||||
gitlab (~> 4.19)
|
||||
|
|
@ -2027,7 +2027,7 @@ DEPENDENCIES
|
|||
gitlab-utils!
|
||||
gitlab_chronic_duration (~> 0.12)
|
||||
gitlab_omniauth-ldap (~> 2.2.0)
|
||||
gitlab_quality-test_tooling (~> 1.23.0)
|
||||
gitlab_quality-test_tooling (~> 1.24.0)
|
||||
gon (~> 6.4.0)
|
||||
google-apis-androidpublisher_v3 (~> 0.34.0)
|
||||
google-apis-cloudbilling_v1 (~> 0.21.0)
|
||||
|
|
|
|||
|
|
@ -13,7 +13,6 @@ query getUserAchievements($id: UserID!) {
|
|||
namespace {
|
||||
id
|
||||
fullPath
|
||||
achievementsPath
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ import { convertToGraphQLId } from '~/graphql_shared/utils';
|
|||
import { s__ } from '~/locale';
|
||||
import { TYPENAME_USER } from '~/graphql_shared/constants';
|
||||
import timeagoMixin from '~/vue_shared/mixins/timeago';
|
||||
import { joinPaths } from '~/lib/utils/url_utility';
|
||||
import getUserAchievements from './graphql/get_user_achievements.query.graphql';
|
||||
|
||||
export const MAX_VISIBLE_ACHIEVEMENTS = 7;
|
||||
|
|
@ -54,7 +53,7 @@ export default {
|
|||
description,
|
||||
namespace: namespace && {
|
||||
fullPath: namespace.fullPath,
|
||||
webUrl: joinPaths(this.rootUrl, namespace.achievementsPath),
|
||||
webUrl: this.rootUrl + namespace.fullPath,
|
||||
},
|
||||
count,
|
||||
};
|
||||
|
|
|
|||
|
|
@ -36,10 +36,6 @@ module Ci
|
|||
end
|
||||
end
|
||||
|
||||
event :canceling do
|
||||
transition CANCELABLE_STATUSES.map(&:to_sym) => :canceling
|
||||
end
|
||||
|
||||
event :pending do
|
||||
transition all => :pending
|
||||
end
|
||||
|
|
@ -55,6 +51,14 @@ module Ci
|
|||
event :actionize do
|
||||
transition created: :manual
|
||||
end
|
||||
|
||||
event :start_cancel do
|
||||
transition CANCELABLE_STATUSES.map(&:to_sym) + [:manual] => :canceling
|
||||
end
|
||||
|
||||
event :finish_cancel do
|
||||
transition CANCELABLE_STATUSES.map(&:to_sym) + [:manual, :canceling] => :canceled
|
||||
end
|
||||
end
|
||||
|
||||
def retryable?
|
||||
|
|
@ -83,7 +87,7 @@ module Ci
|
|||
when 'success'
|
||||
success!
|
||||
when 'canceled'
|
||||
cancel!
|
||||
finish_cancel!
|
||||
when 'failed', 'skipped'
|
||||
drop!
|
||||
else
|
||||
|
|
|
|||
|
|
@ -228,7 +228,7 @@ module Ci
|
|||
transition any => :success
|
||||
end
|
||||
|
||||
event :canceling do
|
||||
event :start_cancel do
|
||||
transition any - [:canceling, :canceled] => :canceling
|
||||
end
|
||||
|
||||
|
|
@ -883,7 +883,7 @@ module Ci
|
|||
when 'running' then run
|
||||
when 'success' then succeed
|
||||
when 'failed' then drop
|
||||
when 'canceling' then canceling
|
||||
when 'canceling' then start_cancel
|
||||
when 'canceled' then cancel
|
||||
when 'skipped' then skip
|
||||
when 'manual' then block
|
||||
|
|
|
|||
|
|
@ -120,7 +120,7 @@ module Ci
|
|||
transition any - [:success] => :success
|
||||
end
|
||||
|
||||
event :canceling do
|
||||
event :start_cancel do
|
||||
transition any - [:canceling, :canceled] => :canceling
|
||||
end
|
||||
|
||||
|
|
@ -149,7 +149,7 @@ module Ci
|
|||
when 'running' then run
|
||||
when 'success' then succeed
|
||||
when 'failed' then drop
|
||||
when 'canceling' then canceling
|
||||
when 'canceling' then start_cancel
|
||||
when 'canceled' then cancel
|
||||
when 'manual' then block
|
||||
when 'scheduled' then delay
|
||||
|
|
|
|||
|
|
@ -176,7 +176,7 @@ class CommitStatus < Ci::ApplicationRecord
|
|||
|
||||
event :cancel do
|
||||
transition running: :canceling, if: :supports_canceling?
|
||||
transition [:created, :waiting_for_resource, :preparing, :waiting_for_callback, :pending, :manual, :scheduled, :running] => :canceled
|
||||
transition CANCELABLE_STATUSES.map(&:to_sym) + [:manual] => :canceled
|
||||
end
|
||||
|
||||
before_transition [:created, :waiting_for_resource, :preparing, :skipped, :manual, :scheduled] => :pending do |commit_status|
|
||||
|
|
|
|||
|
|
@ -461,6 +461,8 @@ class Deployment < ApplicationRecord
|
|||
succeed!
|
||||
when 'failed'
|
||||
drop!
|
||||
when 'canceling'
|
||||
# no-op
|
||||
when 'canceled'
|
||||
cancel!
|
||||
when 'skipped'
|
||||
|
|
|
|||
|
|
@ -0,0 +1,278 @@
|
|||
---
|
||||
stage: Systems
|
||||
group: Gitaly
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# Bundle URI
|
||||
|
||||
DETAILS:
|
||||
**Status:** Experiment
|
||||
|
||||
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/8939) in GitLab 17.0 [with a flag](../../administration/feature_flags.md) named `gitaly_bundle_uri`. Disabled by default.
|
||||
|
||||
FLAG:
|
||||
On self-managed GitLab, by default this feature is not available.
|
||||
To make it available, an administrator can [enable the feature flag](../feature_flags.md)
|
||||
named `gitaly_bundle_uri`.
|
||||
On GitLab.com and GitLab Dedicated, this feature is not available. This feature
|
||||
is not ready for production use.
|
||||
|
||||
Gitaly supports Git [bundle URIs](https://git-scm.com/docs/bundle-uri). Bundle
|
||||
URIs are locations where Git can download one or more bundles to bootstrap the
|
||||
object database before fetching the remaining objects from a remote. Bundle URI
|
||||
is built in to the Git protocol.
|
||||
|
||||
Using Bundle URI can:
|
||||
|
||||
- Speed up clones and fetches for users with a poor network connection to the
|
||||
GitLab server. The bundles can be stored on a CDN, making them available
|
||||
around the world.
|
||||
- Reduce the load on servers that run CI/CD jobs. If CI/CD jobs can pre-load
|
||||
bundles from somewhere else, the remaining work to incrementally fetch missing
|
||||
objects and references creates a lot less load on the server.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- The Git config [`transfer.bundleURI`](https://git-scm.com/docs/git-config#Documentation/git-config.txt-transferbundleURI)
|
||||
must be enabled on Git clients.
|
||||
- GitLab Runner 16.6 or later.
|
||||
|
||||
- In CI/CD pipeline configuration, the
|
||||
[default Git strategy](../../ci/pipelines/settings.md#choose-the-default-git-strategy)
|
||||
set to `git clone`.
|
||||
|
||||
## Server configuration
|
||||
|
||||
You must configure where the bundles are stored. Gitaly supports the following
|
||||
storage services:
|
||||
|
||||
- Google Cloud Storage
|
||||
- AWS S3 (or compatible)
|
||||
- Azure Blob Storage
|
||||
- Local file storage (**not recommended**)
|
||||
|
||||
### Configure Azure Blob storage
|
||||
|
||||
How you configure Azure Blob storage for Bundle URI depends on the type of
|
||||
installation you have. For self-compiled installations, you must set the
|
||||
`AZURE_STORAGE_ACCOUNT` and `AZURE_STORAGE_KEY` environment variables outside of
|
||||
GitLab.
|
||||
|
||||
::Tabs
|
||||
|
||||
:::TabTitle Linux package (Omnibus)
|
||||
|
||||
Edit `/etc/gitlab/gitlab.rb` and configure the `bundle_uri.go_cloud_url`:
|
||||
|
||||
```ruby
|
||||
gitaly['env'] = {
|
||||
'AZURE_STORAGE_ACCOUNT' => 'azure_storage_account',
|
||||
'AZURE_STORAGE_KEY' => 'azure_storage_key' # or 'AZURE_STORAGE_SAS_TOKEN'
|
||||
}
|
||||
gitaly['configuration'] = {
|
||||
bundle_uri: {
|
||||
go_cloud_url: 'azblob://gitaly-bundleuri'
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
:::TabTitle Self-compiled (source)
|
||||
|
||||
Edit `/home/git/gitaly/config.toml` and configure `go_cloud_url`:
|
||||
|
||||
```toml
|
||||
[bundle_uri]
|
||||
go_cloud_url = "azblob://gitaly-bundleuri"
|
||||
```
|
||||
|
||||
::EndTabs
|
||||
|
||||
### Configure Google Cloud storage
|
||||
|
||||
Google Cloud storage (GCP) authenticates using Application Default Credentials.
|
||||
Set up Application Default Credentials on each Gitaly server using either:
|
||||
|
||||
- The [`gcloud auth application-default login`](https://cloud.google.com/sdk/gcloud/reference/auth/application-default/login)
|
||||
command.
|
||||
- The `GOOGLE_APPLICATION_CREDENTIALS` environment variable. For self-compiled
|
||||
installations, set the environment variable outside of GitLab.
|
||||
|
||||
For more information, see
|
||||
[Application Default Credentials](https://cloud.google.com/docs/authentication/provide-credentials-adc).
|
||||
|
||||
The destination bucket is configured using the `go_cloud_url` option.
|
||||
|
||||
::Tabs
|
||||
|
||||
:::TabTitle Linux package (Omnibus)
|
||||
|
||||
Edit `/etc/gitlab/gitlab.rb` and configure the `go_cloud_url`:
|
||||
|
||||
```ruby
|
||||
gitaly['env'] = {
|
||||
'GOOGLE_APPLICATION_CREDENTIALS' => '/path/to/service.json'
|
||||
}
|
||||
gitaly['configuration'] = {
|
||||
bundle_uri: {
|
||||
go_cloud_url: 'gs://gitaly-bundleuri'
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
:::TabTitle Self-compiled (source)
|
||||
|
||||
Edit `/home/git/gitaly/config.toml` and configure `go_cloud_url`:
|
||||
|
||||
```toml
|
||||
[bundle_uri]
|
||||
go_cloud_url = "gs://gitaly-bundle_uri"
|
||||
```
|
||||
|
||||
::EndTabs
|
||||
|
||||
### Configure S3 storage
|
||||
|
||||
To configure S3 storage authentication:
|
||||
|
||||
- If you authenticate with the AWS CLI, you can use the default AWS session.
|
||||
- Otherwise, you can use the `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`
|
||||
environment variables. For self-compiled installations, set the environment
|
||||
variables outside of GitLab.
|
||||
|
||||
For more information, see
|
||||
[AWS Session documentation](https://docs.aws.amazon.com/sdk-for-go/api/aws/session/).
|
||||
|
||||
The destination bucket and region are configured using the `go_cloud_url` option.
|
||||
|
||||
::Tabs
|
||||
|
||||
:::TabTitle Linux package (Omnibus)
|
||||
|
||||
Edit `/etc/gitlab/gitlab.rb` and configure the `go_cloud_url`:
|
||||
|
||||
```ruby
|
||||
gitaly['env'] = {
|
||||
'AWS_ACCESS_KEY_ID' => 'aws_access_key_id',
|
||||
'AWS_SECRET_ACCESS_KEY' => 'aws_secret_access_key'
|
||||
}
|
||||
gitaly['configuration'] = {
|
||||
bundle_uri: {
|
||||
go_cloud_url: 's3://gitaly-bundle_uri?region=us-west-1'
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
:::TabTitle Self-compiled (source)
|
||||
|
||||
Edit `/home/git/gitaly/config.toml` and configure `go_cloud_url`:
|
||||
|
||||
```toml
|
||||
[bundle_uri]
|
||||
go_cloud_url = "s3://gitaly-bundle_uri?region=us-west-1"
|
||||
```
|
||||
|
||||
::EndTabs
|
||||
|
||||
#### Configure S3-compatible servers
|
||||
|
||||
S3-compatible servers such as MinIO are configured similarly to S3 with the
|
||||
addition of the `endpoint` parameter.
|
||||
|
||||
The following parameters are supported:
|
||||
|
||||
- `region`: The AWS region.
|
||||
- `endpoint`: The endpoint URL.
|
||||
- `disabledSSL`: A value of `true` disables SSL.
|
||||
- `s3ForcePathStyle`: A value of `true` forces path-style addressing.
|
||||
|
||||
::Tabs
|
||||
|
||||
:::TabTitle Linux package (Omnibus)
|
||||
|
||||
Edit `/etc/gitlab/gitlab.rb` and configure the `go_cloud_url`:
|
||||
|
||||
```ruby
|
||||
gitaly['env'] = {
|
||||
'AWS_ACCESS_KEY_ID' => 'minio_access_key_id',
|
||||
'AWS_SECRET_ACCESS_KEY' => 'minio_secret_access_key'
|
||||
}
|
||||
gitaly['configuration'] = {
|
||||
bundle_uri: {
|
||||
go_cloud_url: 's3://gitaly-bundleuri?region=minio&endpoint=my.minio.local:8080&disableSSL=true&s3ForcePathStyle=true'
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
:::TabTitle Self-compiled (source)
|
||||
|
||||
Edit `/home/git/gitaly/config.toml` and configure `go_cloud_url`:
|
||||
|
||||
```toml
|
||||
[bundle_uri]
|
||||
go_cloud_url = "s3://gitaly-bundleuri?region=minio&endpoint=my.minio.local:8080&disableSSL=true&s3ForcePathStyle=true"
|
||||
```
|
||||
|
||||
::EndTabs
|
||||
|
||||
## Generating bundles
|
||||
|
||||
After Gitaly is properly configured, Gitaly can generate bundles, which is a
|
||||
manual process. To generate a bundle for Bundle URI, run:
|
||||
|
||||
```shell
|
||||
sudo /opt/gitlab/embedded/bin/gitaly bundle-uri \
|
||||
--config=<config-file> \
|
||||
--storage=<storage-name> \
|
||||
--repository=<relative-path>
|
||||
```
|
||||
|
||||
This command generates the bundle and stores it on the configured storage service.
|
||||
Gitaly does not automatically refresh the generated bundle, so when want to generate
|
||||
a more recent version of a bundle, you must the run command again.
|
||||
|
||||
You can schedule this command with a tool like `cron(8)`.
|
||||
|
||||
## Bundle URI example
|
||||
|
||||
In the following example, we demonstrate the difference between cloning
|
||||
`gitlab.com/gitlab-org/gitlab.git` with and without using bundle URI.
|
||||
|
||||
```shell
|
||||
$ git -c transfer.bundleURI=false clone https://gitlab.com/gitlab-org/gitlab.git
|
||||
Cloning into 'gitlab'...
|
||||
remote: Enumerating objects: 5271177, done.
|
||||
remote: Total 5271177 (delta 0), reused 0 (delta 0), pack-reused 5271177
|
||||
Receiving objects: 100% (5271177/5271177), 1.93 GiB | 32.93 MiB/s, done.
|
||||
Resolving deltas: 100% (4140349/4140349), done.
|
||||
Updating files: 100% (71304/71304), done.
|
||||
|
||||
$ git -c transfer.bundleURI=true clone https://gitlab.com/gitlab-org/gitlab.git
|
||||
Cloning into 'gitlab'...
|
||||
remote: Enumerating objects: 1322255, done.
|
||||
remote: Counting objects: 100% (611708/611708), done.
|
||||
remote: Total 1322255 (delta 611708), reused 611708 (delta 611708), pack-reused 710547
|
||||
Receiving objects: 100% (1322255/1322255), 539.66 MiB | 22.98 MiB/s, done.
|
||||
Resolving deltas: 100% (1026890/1026890), completed with 223946 local objects.
|
||||
Checking objects: 100% (8388608/8388608), done.
|
||||
Checking connectivity: 1381139, done.
|
||||
Updating files: 100% (71304/71304), done.
|
||||
```
|
||||
|
||||
In the above example:
|
||||
|
||||
- When not using Bundle URI, there were 5,271,177 objects received from the
|
||||
GitLab server.
|
||||
- When using Bundle URL, there were 1,322,255 objects received from the GitLab
|
||||
server.
|
||||
|
||||
This reduction means GitLab needs to pack together fewer objects (in the above
|
||||
example, roughly a quarter of the number of objects) because the client first
|
||||
downloaded the bundle from the storage server.
|
||||
|
||||
## Securing bundles
|
||||
|
||||
The bundles are made accessible to the client using signed URLs. A signed URL is
|
||||
a URL that provides limited permissions and time to make a request. To see if
|
||||
your storage service supports sighed URLs, see the documentation of your storage
|
||||
service.
|
||||
|
|
@ -191,6 +191,11 @@ For more information on the other subcommands, run `gitaly --help`.
|
|||
When backing up or syncing repositories using tools other than GitLab, you must [prevent writes](../../administration/backup_restore/backup_gitlab.md#prevent-writes-and-copy-the-git-repository-data)
|
||||
while copying repository data.
|
||||
|
||||
### Bundle URI
|
||||
|
||||
You can use Git [bundle URIs](https://git-scm.com/docs/bundle-uri) with Gitaly.
|
||||
For more information, see the [Bundle URI documentation](bundle_uri.md).
|
||||
|
||||
## Gitaly Cluster
|
||||
|
||||
Git storage is provided through the Gitaly service in GitLab, and is essential to the operation of
|
||||
|
|
|
|||
|
|
@ -1552,7 +1552,7 @@ curl --request POST --header "PRIVATE-TOKEN: <your-token>" \
|
|||
| `namespace_id` | integer | No | Namespace for the new project (defaults to the current user's namespace). |
|
||||
| `only_allow_merge_if_all_discussions_are_resolved` | boolean | No | Set whether merge requests can only be merged when all the discussions are resolved. |
|
||||
| `only_allow_merge_if_all_status_checks_passed` | boolean | No | Indicates that merges of merge requests should be blocked unless all status checks have passed. Defaults to false. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/369859) in GitLab 15.5 with feature flag `only_allow_merge_if_all_status_checks_passed` disabled by default. Ultimate only. |
|
||||
| `only_allow_merge_if_pipeline_succeeds` | boolean | No | Set whether merge requests can only be merged with successful pipelines. This setting is named [**Pipelines must succeed**](../user/project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge) in the project settings. |
|
||||
| `only_allow_merge_if_pipeline_succeeds` | boolean | No | Set whether merge requests can only be merged with successful pipelines. This setting is named [**Pipelines must succeed**](../user/project/merge_requests/auto_merge.md#require-a-successful-pipeline-for-merge) in the project settings. |
|
||||
| `packages_enabled` | boolean | No | Enable or disable packages repository feature. |
|
||||
| `pages_access_level` | string | No | One of `disabled`, `private`, `enabled`, or `public`. |
|
||||
| `printing_merge_request_link_enabled` | boolean | No | Show link to create/view merge request when pushing from the command line. |
|
||||
|
|
|
|||
|
|
@ -355,7 +355,7 @@ and error messages.
|
|||
|
||||
### `A CI/CD pipeline must run and be successful before merge` message
|
||||
|
||||
This message is shown if the [**Pipelines must succeed**](../user/project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge)
|
||||
This message is shown if the [**Pipelines must succeed**](../user/project/merge_requests/auto_merge.md#require-a-successful-pipeline-for-merge)
|
||||
setting is enabled in the project and a pipeline has not yet run successfully.
|
||||
This also applies if the pipeline has not been created yet, or if you are waiting
|
||||
for an external CI service.
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ In blocking manual jobs:
|
|||
defined inside [`rules`](../yaml/index.md#rules).
|
||||
- The pipeline stops at the stage where the job is defined. To let the pipeline
|
||||
continue running, [run the manual job](#run-a-manual-job).
|
||||
- Merge requests in projects with [**Pipelines must succeed**](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge)
|
||||
- Merge requests in projects with [**Pipelines must succeed**](../../user/project/merge_requests/auto_merge.md#require-a-successful-pipeline-for-merge)
|
||||
enabled can't be merged with a blocked pipeline.
|
||||
- The pipeline shows a status of **blocked**.
|
||||
|
||||
|
|
|
|||
|
|
@ -244,7 +244,7 @@ notes. Check the **Activity** section in the **Overview** tab for a message simi
|
|||
|
||||
### Cannot use auto-merge
|
||||
|
||||
You cannot use [auto-merge](../../user/project/merge_requests/merge_when_pipeline_succeeds.md)
|
||||
You cannot use [auto-merge](../../user/project/merge_requests/auto_merge.md)
|
||||
(formerly **Merge when pipeline succeeds**) to skip the merge train, when merge trains are enabled.
|
||||
See [issue 12267](https://gitlab.com/gitlab-org/gitlab/-/issues/12267) for more information.
|
||||
|
||||
|
|
@ -264,7 +264,7 @@ You can:
|
|||
|
||||
### Unable to add to the merge train
|
||||
|
||||
When [**Pipelines must succeed**](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge)
|
||||
When [**Pipelines must succeed**](../../user/project/merge_requests/auto_merge.md#require-a-successful-pipeline-for-merge)
|
||||
is enabled, but the latest pipeline failed:
|
||||
|
||||
- The **Set to auto-merge** or **Merge** options are not available.
|
||||
|
|
|
|||
|
|
@ -67,6 +67,6 @@ on your GitLab instance.
|
|||
### Successful merged results pipeline overrides a failed branch pipeline
|
||||
|
||||
A failed branch pipeline is sometimes ignored when the
|
||||
[**Pipelines must succeed** setting](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge)
|
||||
[**Pipelines must succeed** setting](../../user/project/merge_requests/auto_merge.md#require-a-successful-pipeline-for-merge)
|
||||
is activated.
|
||||
[Issue 385841](https://gitlab.com/gitlab-org/gitlab/-/issues/385841) is open to track this.
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ 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).
|
||||
|
||||
When the project has [**Pipelines must succeed**](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge) enabled
|
||||
When the project has [**Pipelines must succeed**](../../user/project/merge_requests/auto_merge.md#require-a-successful-pipeline-for-merge) enabled
|
||||
and both pipelines types are present, the merge request pipelines are checked,
|
||||
not the branch pipelines.
|
||||
|
||||
|
|
|
|||
|
|
@ -19,12 +19,12 @@ for tags, but the workflow prevents tag pipelines, the job never runs.
|
|||
|
||||
Some example `if` clauses for `workflow: rules`:
|
||||
|
||||
| Example rules | Details |
|
||||
|------------------------------------------------------|---------|
|
||||
| `if: '$CI_PIPELINE_SOURCE == "merge_request_event"'` | Control when merge request pipelines run. |
|
||||
| Example rules | Details |
|
||||
|------------------------------------------------------|-----------------------------------------------------------|
|
||||
| `if: '$CI_PIPELINE_SOURCE == "merge_request_event"'` | Control when merge request pipelines run. |
|
||||
| `if: '$CI_PIPELINE_SOURCE == "push"'` | Control when both branch pipelines and tag pipelines run. |
|
||||
| `if: $CI_COMMIT_TAG` | Control when tag pipelines run. |
|
||||
| `if: $CI_COMMIT_BRANCH` | Control when branch pipelines run. |
|
||||
| `if: $CI_COMMIT_TAG` | Control when tag pipelines run. |
|
||||
| `if: $CI_COMMIT_BRANCH` | Control when branch pipelines run. |
|
||||
|
||||
See the [common `if` clauses for `rules`](../jobs/job_rules.md#common-if-clauses-with-predefined-variables) for more examples.
|
||||
|
||||
|
|
@ -176,7 +176,7 @@ include:
|
|||
|
||||
If a merge request displays `Checking pipeline status.`, but the message never goes
|
||||
away (the "spinner" never stops spinning), it might be due to `workflow:rules`.
|
||||
This issue can happen if a project has [**Pipelines must succeed**](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge)
|
||||
This issue can happen if a project has [**Pipelines must succeed**](../../user/project/merge_requests/auto_merge.md#require-a-successful-pipeline-for-merge)
|
||||
enabled, but the `workflow:rules` prevent a pipeline from running for the merge request.
|
||||
|
||||
For example, with this workflow, merge requests cannot be merged, because no
|
||||
|
|
|
|||
|
|
@ -314,15 +314,20 @@ In GitLab 16.8, 16.9, and 16.10, on GitLab Dedicated, GitLab Duo Chat is availab
|
|||
|
||||
## Disable GitLab Duo Chat
|
||||
|
||||
To disable GitLab Duo Chat, follow the instructions for
|
||||
If you have a Premium or Ultimate subscription, the **GitLab Duo Chat** button
|
||||
is always displayed in the upper-right corner of the UI, and on the left sidebar under **Help**.
|
||||
|
||||
You do, however, have an option for changing the availability of GitLab Duo Chat.
|
||||
|
||||
### Change the data used by GitLab Duo Chat
|
||||
|
||||
To limit the data that Duo Chat has access to, follow the instructions for
|
||||
[disabling GitLab Duo features](ai_features_enable.md).
|
||||
|
||||
When you disable GitLab Duo features, GitLab Duo Chat no longer uses your organization's
|
||||
data when responding to questions. For example, you can no longer ask about your issues or epics.
|
||||
|
||||
However, the **GitLab Duo Chat** button continues to be displayed in the upper-right corner
|
||||
and on the left sidebar under **Help**, and
|
||||
you can continue to ask generic questions about GitLab.
|
||||
When you make this change, the button is not removed. Instead,
|
||||
GitLab Duo Chat no longer uses your organization's data when responding to questions.
|
||||
For example, you can no longer ask about your issues or epics. You can, however,
|
||||
continue to ask generic questions about GitLab.
|
||||
|
||||
## Use GitLab Duo Chat in the GitLab UI
|
||||
|
||||
|
|
|
|||
|
|
@ -352,7 +352,7 @@ that inherited them.
|
|||
You can configure all child projects in your group to require a complete and successful pipeline before
|
||||
merge.
|
||||
|
||||
See also [the project-level setting](../project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge).
|
||||
See also [the project-level setting](../project/merge_requests/auto_merge.md#require-a-successful-pipeline-for-merge).
|
||||
|
||||
Prerequisites:
|
||||
|
||||
|
|
@ -371,7 +371,7 @@ To enable this setting:
|
|||
|
||||
You can configure [skipped pipelines](../../ci/pipelines/index.md#skip-a-pipeline) from preventing merge requests from being merged.
|
||||
|
||||
See also [the project-level setting](../project/merge_requests/merge_when_pipeline_succeeds.md#allow-merge-after-skipped-pipelines).
|
||||
See also [the project-level setting](../project/merge_requests/auto_merge.md#allow-merge-after-skipped-pipelines).
|
||||
|
||||
Prerequisites:
|
||||
|
||||
|
|
|
|||
|
|
@ -139,6 +139,14 @@ Microsoft has [announced](https://azure.microsoft.com/en-us/updates/azure-ad-is-
|
|||
Azure AD sends up to 150 groups in the groups claim. When users are members of more than 150 groups Azure AD sends a
|
||||
group overage claim attribute in the SAML response. Then group memberships must be obtained using the Microsoft Graph API.
|
||||
|
||||
The [Graph API endpoint](https://learn.microsoft.com/en-us/graph/api/user-list-transitivememberof?view=graph-rest-1.0&tabs=http#http-request) supports only a
|
||||
[user object ID](https://learn.microsoft.com/en-us/partner-center/find-ids-and-domain-names#find-the-user-object-id) or
|
||||
[userPrincipalName](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/plan-connect-userprincipalname#what-is-userprincipalname)
|
||||
as the [configured](../../../user/group/saml_sso/index.md#azure) Unique User Identifier (Name identifier) attribute.
|
||||
|
||||
When the integration processes Group Sync, only Group Links configured with
|
||||
group unique identifiers (like `12345678-9abc-def0-1234-56789abcde`) are supported.
|
||||
|
||||
To integrate Microsoft Azure AD, you:
|
||||
|
||||
- Configure Azure AD to enable GitLab to communicate with the Microsoft Graph API.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,188 @@
|
|||
---
|
||||
stage: Create
|
||||
group: Code Review
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
description: "Set auto-merge on a merge request when you have reviewed its content, so it can merge without intervention when all merge checks pass."
|
||||
---
|
||||
|
||||
# Auto-merge
|
||||
|
||||
DETAILS:
|
||||
**Tier:** Free, Premium, Ultimate
|
||||
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
|
||||
|
||||
> - **Merge when pipeline succeeds** and **Add to merge train when pipeline succeeds** [renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/409530) to **Auto-merge** in GitLab 16.0 [with a flag](../../../administration/feature_flags.md) named `auto_merge_labels_mr_widget`. Enabled by default.
|
||||
> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/120922) in GitLab 16.0. Feature flag `auto_merge_labels_mr_widget` removed.
|
||||
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/10874) in GitLab 16.5 [with two flags](../../../administration/feature_flags.md) named `merge_when_checks_pass` and `additional_merge_when_checks_ready`. Disabled by default.
|
||||
> - [Enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/412995) the flags `merge_when_checks_pass` and `additional_merge_when_checks_ready` on GitLab.com in GitLab 17.0.
|
||||
|
||||
FLAG:
|
||||
The availability of this feature is controlled by a feature flag.
|
||||
For more information, see the history.
|
||||
This feature is available for testing, but not ready for production use.
|
||||
|
||||
When the `merge_when_checks_pass` feature flag is enabled, if the content of a merge request is ready to merge,
|
||||
you can select **Set to auto-merge**. The merge request auto-merges when all required checks complete successfully, and you don't need to remember to manually merge the merge request.
|
||||
|
||||
After you set auto-merge, these checks must all pass before the merge request is merged:
|
||||
|
||||
- All required approvals must be given.
|
||||
- No other merge requests block this merge request.
|
||||
- No merge conflicts exist.
|
||||
- A CI/CD pipeline must complete successfully, regardless of the [project setting](#require-a-successful-pipeline-for-merge).
|
||||
- All discussions are resolved.
|
||||
- The merge request is not a **Draft**.
|
||||
- All external status checks have passed.
|
||||
- The merge request must be open.
|
||||
- No denied policies exist.
|
||||
- If your project
|
||||
[requires merge requests to reference a Jira issue](../../../integration/jira/issues.md#require-associated-jira-issue-for-merge-requests-to-be-merged),
|
||||
the merge request title or description contains a Jira issue link.
|
||||
|
||||
For a full list of checks and their API equivalents, see
|
||||
[Merge status](../../../api/merge_requests.md#merge-status).
|
||||
|
||||
|
||||
|
||||
## Auto-merge a merge request
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must have at least the Developer role in the project.
|
||||
- If your project configuration requires it, all threads in the
|
||||
merge request [must be resolved](index.md#resolve-a-thread).
|
||||
- The merge request must have received all required approvals.
|
||||
- Merge trains are not supported. For more information,
|
||||
see [issue 443395](https://gitlab.com/gitlab-org/gitlab/-/issues/443395).
|
||||
|
||||
To do this when pushing from the command line, use the `merge_request.merge_when_pipeline_succeeds`
|
||||
[push option](../push_options.md).
|
||||
|
||||
To do this from the GitLab user interface:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your project.
|
||||
1. Select **Code > Merge requests**.
|
||||
1. Select the merge request to edit.
|
||||
1. Scroll to the merge request reports section.
|
||||
1. Optional. Select your desired merge options, such as **Delete source branch**,
|
||||
**Squash commits**, or **Edit commit message**.
|
||||
1. Select **Auto-merge**.
|
||||
|
||||
If you add a new comment to the merge request after you select **Auto-merge**,
|
||||
but before the pipeline completes, GitLab blocks the merge until you
|
||||
resolve all existing threads.
|
||||
|
||||
## Pipeline success for auto-merge
|
||||
|
||||
If the pipeline succeeds, the merge request merges. If the pipeline fails, the author
|
||||
can either retry any failed jobs, or push new commits to fix the failure:
|
||||
|
||||
- If a retried job succeeds on the second try, the merge request merges.
|
||||
- If you add new commits to the merge request, GitLab cancels the request
|
||||
to ensure the new changes receive a review before merge.
|
||||
- If you add new commits to the _target_ branch of the merge request, and your project
|
||||
allows only fast-forward merge requests, GitLab cancels the request to prevent merge conflicts.
|
||||
|
||||
For stricter control on pipeline status, you can also
|
||||
[require a successful pipeline](#require-a-successful-pipeline-for-merge) before merge.
|
||||
|
||||
## Cancel an auto-merge
|
||||
|
||||
You can cancel auto-merge on a merge request.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must either be the author of the merge request, or a project member with
|
||||
at least the Developer role.
|
||||
- The merge request's pipeline must still be in progress.
|
||||
|
||||
To do this:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your project.
|
||||
1. Select **Code > Merge requests**.
|
||||
1. Select the merge request to edit.
|
||||
1. Scroll to the merge request reports section.
|
||||
1. Select **Cancel auto-merge**.
|
||||
|
||||
|
||||
|
||||
## Require a successful pipeline for merge
|
||||
|
||||
You can configure your project to require a complete and successful pipeline before
|
||||
merge. This configuration works for both:
|
||||
|
||||
- GitLab CI/CD pipelines.
|
||||
- Pipelines run from an [external CI integration](../integrations/index.md#available-integrations).
|
||||
|
||||
As a result, [disabling GitLab CI/CD pipelines](../../../ci/pipelines/settings.md#disable-gitlab-cicd-pipelines)
|
||||
does not disable this feature, but you can use pipelines from external
|
||||
CI providers with it.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- Ensure your project's CI/CD configuration runs a pipeline for every merge request.
|
||||
- You must have at least the Maintainer role in the project.
|
||||
|
||||
To enable this setting:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your project.
|
||||
1. Select **Settings > Merge requests**.
|
||||
1. Scroll to **Merge checks**, and select **Pipelines must succeed**.
|
||||
This setting also prevents merge requests from merging if there is no pipeline,
|
||||
which can [conflict with some rules](#merge-request-cant-merge-despite-no-failed-pipeline).
|
||||
1. Select **Save**.
|
||||
|
||||
If [multiple pipeline types run for the same merge request](#merge-request-can-still-be-merged-despite-a-failed-pipeline),
|
||||
merge request pipelines take precedence over other pipeline types. For example,
|
||||
an older but successful merge request pipeline allows a merge request to be merged,
|
||||
despite a newer but failed branch pipeline.
|
||||
|
||||
### Allow merge after skipped pipelines
|
||||
|
||||
When you set **Pipelines must succeed** for a project,
|
||||
[skipped pipelines](../../../ci/pipelines/index.md#skip-a-pipeline) prevent
|
||||
merge requests from merging.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must have at least the Maintainer role in the project.
|
||||
|
||||
To change this behavior:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your project.
|
||||
1. Select **Settings > Merge requests**.
|
||||
1. Under **Merge checks**:
|
||||
- Select **Pipelines must succeed**.
|
||||
- Select **Skipped pipelines are considered successful**.
|
||||
1. Select **Save**.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Merge request can't merge despite no failed pipeline
|
||||
|
||||
In some cases, you can [require a successful pipeline for merge](#require-a-successful-pipeline-for-merge),
|
||||
but be unable to merge a merge request with no failed pipelines. The setting requires
|
||||
the existence of a successful pipeline, not the absence of failed pipelines. If the merge request
|
||||
has no pipelines at all, it is not considered to have a successful pipeline and cannot be merged.
|
||||
|
||||
When you enable this setting, use [`rules`](../../../ci/yaml/index.md#rules)
|
||||
or [`workflow:rules`](../../../ci/yaml/index.md#workflowrules) to ensure pipelines
|
||||
run for every merge request.
|
||||
|
||||
### Merge request can still be merged despite a failed pipeline
|
||||
|
||||
In some cases, you can [require a successful pipeline for merge](#require-a-successful-pipeline-for-merge),
|
||||
but still merge a merge request with a failed pipeline.
|
||||
|
||||
Merge request pipelines have the highest priority for the **Pipelines must succeed** setting.
|
||||
If multiple pipeline types run for the same merge request, only the merge request pipelines
|
||||
are checked for success.
|
||||
|
||||
Multiple pipeline types in the same merge request can be caused by:
|
||||
|
||||
- A [`rules`](../../../ci/yaml/index.md#rules) configuration that causes [duplicate pipelines](../../../ci/jobs/job_rules.md#avoid-duplicate-pipelines):
|
||||
one merge request pipeline and one branch pipeline. In this case, the status of the
|
||||
latest merge request pipeline determines if a merge request can be merged, not the branch pipeline.
|
||||
- Pipelines triggered by external tools that target the same branch as the merge request.
|
||||
|
||||
In all cases, update your CI/CD configuration to prevent multiple pipeline types for the same merge request.
|
||||
|
|
@ -1,189 +1,11 @@
|
|||
---
|
||||
stage: Create
|
||||
group: Code Review
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
description: "Set auto-merge on a merge request when you have reviewed its content, so it can merge without intervention when all merge checks pass."
|
||||
redirect_to: 'auto_merge.md'
|
||||
remove_date: '2024-10-02'
|
||||
---
|
||||
|
||||
# Auto-merge
|
||||
This document was moved to [another location](auto_merge.md).
|
||||
|
||||
DETAILS:
|
||||
**Tier:** Free, Premium, Ultimate
|
||||
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
|
||||
|
||||
> - **Merge when pipeline succeeds** and **Add to merge train when pipeline succeeds** [renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/409530) to **Auto-merge** in GitLab 16.0 [with a flag](../../../administration/feature_flags.md) named `auto_merge_labels_mr_widget`. Enabled by default.
|
||||
> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/120922) in GitLab 16.0. Feature flag `auto_merge_labels_mr_widget` removed.
|
||||
|
||||
If the content of a merge request is ready to merge, use **Set to auto-merge** on
|
||||
the merge request. You don't have to remember later to merge the work manually. If set,
|
||||
a merge request auto-merges when all these conditions are met:
|
||||
|
||||
- The merge request pipeline must complete successfully.
|
||||
- All required approvals must be given.
|
||||
|
||||
|
||||
|
||||
The [merge when checks pass](#merge-when-checks-pass) feature, available in
|
||||
GitLab 16.9 and later, adds more checks to the auto-merge process.
|
||||
|
||||
## Auto-merge a merge request
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must have at least the Developer role in the project.
|
||||
- If the project is configured to require it, all threads in the
|
||||
merge request [must be resolved](index.md#resolve-a-thread).
|
||||
- The merge request must have received all required approvals.
|
||||
|
||||
To do this when pushing from the command line, use the `merge_request.merge_when_pipeline_succeeds`
|
||||
[push option](../push_options.md).
|
||||
|
||||
To do this from the GitLab user interface:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your project.
|
||||
1. Select **Code > Merge requests**.
|
||||
1. Select the merge request to edit.
|
||||
1. Scroll to the merge request reports section.
|
||||
1. Optional. Select your desired merge options, such as **Delete source branch**,
|
||||
**Squash commits**, or **Edit commit message**.
|
||||
1. Select **Auto-merge**.
|
||||
|
||||
If a new comment is added to the merge request after you select **Auto-merge**,
|
||||
but before the pipeline completes, GitLab blocks the merge until you
|
||||
resolve all existing threads.
|
||||
|
||||
### Merge when pipeline succeeds
|
||||
|
||||
If the pipeline succeeds, the merge request is merged. If the pipeline fails, the
|
||||
author can either retry any failed jobs, or push new commits to fix the failure:
|
||||
|
||||
- If a retried job succeeds on the second try, the merge request is merged.
|
||||
- If new commits are added to the merge request, GitLab cancels the request
|
||||
to ensure the new changes are reviewed before merge.
|
||||
- If new commits are added to the target branch of the merge request and
|
||||
fast-forward only merge request is configured, GitLab cancels the request
|
||||
to prevent merge conflicts.
|
||||
|
||||
### Merge when checks pass
|
||||
|
||||
DETAILS:
|
||||
**Tier:** Free, Premium, Ultimate
|
||||
**Offering:** GitLab.com, Self-managed
|
||||
|
||||
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/10874) in GitLab 16.5 [with two flags](../../../administration/feature_flags.md) named `merge_when_checks_pass` and `additional_merge_when_checks_ready`. Disabled by default.
|
||||
> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/412995) in GitLab 16.9.
|
||||
|
||||
FLAG:
|
||||
On self-managed GitLab, by default this feature is not available. To enable the feature,
|
||||
an administrator can [enable the feature flags](../../../administration/feature_flags.md)
|
||||
named `merge_when_checks_pass` and `additional_merge_when_checks_ready`.
|
||||
On GitLab.com, this feature is available. On GitLab Dedicated, this feature is not available.
|
||||
|
||||
In GitLab 16.9 and later, **Merge when checks pass** adds more checks to the auto-merge
|
||||
process. When set to auto-merge, all of these checks must pass for a merge request to merge:
|
||||
|
||||
- The merge request pipeline must complete successfully, regardless of the project setting.
|
||||
- All required approvals must be given.
|
||||
- The merge request must not be a **Draft**.
|
||||
- All discussions must be resolved.
|
||||
- All blocking merge requests must be merged or closed.
|
||||
|
||||
## Cancel an auto-merge
|
||||
|
||||
If a merge request is set to auto-merge, you can cancel it.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must either be the author of the merge request, or a project member with
|
||||
at least the Developer role.
|
||||
- The merge request's pipeline must still be in progress.
|
||||
|
||||
To do this:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your project.
|
||||
1. Select **Code > Merge requests**.
|
||||
1. Select the merge request to edit.
|
||||
1. Scroll to the merge request reports section.
|
||||
1. Select **Cancel auto-merge**.
|
||||
|
||||
|
||||
|
||||
## Require a successful pipeline for merge
|
||||
|
||||
You can configure your project to require a complete and successful pipeline before
|
||||
merge. This configuration works for both:
|
||||
|
||||
- GitLab CI/CD pipelines.
|
||||
- Pipelines run from an [external CI integration](../integrations/index.md#available-integrations).
|
||||
|
||||
As a result, [disabling GitLab CI/CD pipelines](../../../ci/pipelines/settings.md#disable-gitlab-cicd-pipelines)
|
||||
does not disable this feature, but you can use pipelines from external
|
||||
CI providers with it.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- Ensure CI/CD is configured to run a pipeline for every merge request.
|
||||
- You must have at least the Maintainer role in the project.
|
||||
|
||||
To enable this setting:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your project.
|
||||
1. Select **Settings > Merge requests**.
|
||||
1. Scroll to **Merge checks**, and select **Pipelines must succeed**.
|
||||
This setting also prevents merge requests from being merged if there is no pipeline,
|
||||
which can [conflict with some rules](#merge-request-cannot-be-merged-despite-no-failed-pipeline).
|
||||
1. Select **Save**.
|
||||
|
||||
If [multiple pipeline types run for the same merge request](#merge-request-can-still-be-merged-despite-a-failed-pipeline),
|
||||
merge request pipelines take precedence over other pipeline types. For example,
|
||||
an older but successful merge request pipeline allows a merge request to be merged,
|
||||
despite a newer but failed branch pipeline.
|
||||
|
||||
### Allow merge after skipped pipelines
|
||||
|
||||
When the **Pipelines must succeed** checkbox is checked,
|
||||
[skipped pipelines](../../../ci/pipelines/index.md#skip-a-pipeline) prevent
|
||||
merge requests from being merged.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must have at least the Maintainer role in the project.
|
||||
|
||||
To change this behavior:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your project.
|
||||
1. Select **Settings > Merge requests**.
|
||||
1. Under **Merge checks**:
|
||||
- Select **Pipelines must succeed**.
|
||||
- Select **Skipped pipelines are considered successful**.
|
||||
1. Select **Save**.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Merge request cannot be merged despite no failed pipeline
|
||||
|
||||
In some cases, you can [require a successful pipeline for merge](#require-a-successful-pipeline-for-merge),
|
||||
but be unable to merge a merge request with no failed pipelines. The setting requires
|
||||
the existence of a successful pipeline, not the absence of failed pipelines. If the merge request
|
||||
has no pipelines at all, it is not considered to have a successful pipeline and cannot be merged.
|
||||
|
||||
When the setting is enabled, use [`rules`](../../../ci/yaml/index.md#rules) or [`workflow:rules`](../../../ci/yaml/index.md#workflowrules)
|
||||
to ensure pipelines run for every merge request.
|
||||
|
||||
### Merge request can still be merged despite a failed pipeline
|
||||
|
||||
In some cases, you can [require a successful pipeline for merge](#require-a-successful-pipeline-for-merge),
|
||||
but still merge a merge request with a failed pipeline.
|
||||
|
||||
Merge request pipelines have the highest priority for the **Pipelines must succeed** setting.
|
||||
If multiple pipeline types run for the same merge request, only the merge request pipelines
|
||||
are checked for success.
|
||||
|
||||
Multiple pipeline types in the same merge request can be caused by:
|
||||
|
||||
- A [`rules`](../../../ci/yaml/index.md#rules) configuration that causes [duplicate pipelines](../../../ci/jobs/job_rules.md#avoid-duplicate-pipelines):
|
||||
one merge request pipeline and one branch pipeline. In this case, the status of the
|
||||
latest merge request pipeline determines if a merge request can be merged, not the branch pipeline.
|
||||
- Pipelines triggered by external tools that target the same branch as the merge request.
|
||||
|
||||
In all cases, update your CI/CD configuration to prevent multiple pipeline types for the same merge request.
|
||||
<!-- This redirect file can be deleted after <2024-10-02>. -->
|
||||
<!-- Redirects that point to other docs in the same project expire in three months. -->
|
||||
<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
|
||||
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ module Gitlab
|
|||
|
||||
def initialize(repository, extra_namespace: nil, expires_in: 2.weeks)
|
||||
@repository = repository
|
||||
@namespace = "#{repository.full_path}"
|
||||
@namespace = repository.full_path.to_s
|
||||
@namespace += ":#{repository.project.id}" if repository.project
|
||||
@namespace = "#{@namespace}:#{extra_namespace}" if extra_namespace
|
||||
@expires_in = expires_in
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ module Gitlab
|
|||
private
|
||||
|
||||
def counter_key(event)
|
||||
"#{event}".to_sym
|
||||
event.to_s.to_sym
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ module Kramdown
|
|||
def convert_codeblock(el, _opts)
|
||||
# Although tildes are supported in CommonMark, backticks are more common
|
||||
"```#{el.options[:lang]}\n" +
|
||||
el.value.split("\n").map { |l| l.empty? ? "" : "#{l}" }.join("\n") +
|
||||
el.value.split("\n").map { |l| l.empty? ? "" : l.to_s }.join("\n") +
|
||||
"\n```\n\n"
|
||||
end
|
||||
|
||||
|
|
|
|||
|
|
@ -101,7 +101,7 @@ namespace :gettext do
|
|||
puts " #{message_id}"
|
||||
errors.each do |error|
|
||||
spaces = ' ' * 4
|
||||
error = error.lines.join("#{spaces}")
|
||||
error = error.lines.join(spaces.to_s)
|
||||
puts "#{spaces}#{error}"
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -165,7 +165,7 @@ class GroupSeeder
|
|||
group = Group.find(group_id)
|
||||
label_title = FFaker::Product.brand
|
||||
|
||||
Labels::CreateService.new(title: label_title, color: "#{::Gitlab::Color.color_for(label_title)}").execute(group: group)
|
||||
Labels::CreateService.new(title: label_title, color: ::Gitlab::Color.color_for(label_title).to_s).execute(group: group)
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ module QA
|
|||
query << "target_type=#{CGI.escape(target_type)}" if target_type
|
||||
path = [api_get_events]
|
||||
path << "?#{query.join("&")}" unless query.empty?
|
||||
parse_body(api_get_from("#{path.join}"))
|
||||
parse_body(api_get_from(path.join.to_s))
|
||||
end
|
||||
|
||||
private
|
||||
|
|
|
|||
|
|
@ -44,8 +44,8 @@ module QA
|
|||
|
||||
Page::Project::Job::Show.perform do |job|
|
||||
aggregate_failures 'main CI is not overridden' do
|
||||
expect(job.output).not_to have_content("#{unexpected_text}")
|
||||
expect(job.output).to have_content("#{expected_text}")
|
||||
expect(job.output).not_to have_content(unexpected_text.to_s)
|
||||
expect(job.output).to have_content(expected_text.to_s)
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ module QA
|
|||
|
||||
def create_many_todos
|
||||
30.times do |i|
|
||||
create_a_todo_api_req("#{@group_name}%2F#{@project_name}", "#{i + 1}")
|
||||
create_a_todo_api_req("#{@group_name}%2F#{@project_name}", (i + 1).to_s)
|
||||
end
|
||||
@urls[:todos_page] = ENV['GITLAB_ADDRESS'] + "/dashboard/todos"
|
||||
$stdout.puts "Created many todos: #{@urls[:todos_page]}"
|
||||
|
|
@ -85,7 +85,7 @@ module QA
|
|||
|
||||
def create_many_labels
|
||||
30.times do |i|
|
||||
create_a_label_api_req("#{@group_name}%2F#{@project_name}", "label#{i}", "#{Faker::Color.hex_color}")
|
||||
create_a_label_api_req("#{@group_name}%2F#{@project_name}", "label#{i}", Faker::Color.hex_color.to_s)
|
||||
end
|
||||
@urls[:labels_page] = @urls[:project_page] + "/labels"
|
||||
$stdout.puts "Created many labels: #{@urls[:labels_page]}"
|
||||
|
|
@ -126,7 +126,7 @@ module QA
|
|||
|
||||
labels_list = (0..15).map { |i| "label#{i}" }.join(',')
|
||||
# Add description and labels
|
||||
update_an_issue_api_req("#{@group_name}%2F#{@project_name}", issue_id, "#{Faker::Lorem.sentences(500).join(" ")}", labels_list)
|
||||
update_an_issue_api_req("#{@group_name}%2F#{@project_name}", issue_id, Faker::Lorem.sentences(500).join(" ").to_s, labels_list)
|
||||
@urls[:large_issue] = @urls[:project_page] + "/issues/#{issue_id}"
|
||||
$stdout.puts "Created an issue with many discussions: #{@urls[:large_issue]}"
|
||||
end
|
||||
|
|
|
|||
|
|
@ -74,7 +74,19 @@ def generate_snowplow_table
|
|||
@initial_max_timestamp ||= events.map { |e| e['rawEvent']['parameters']['dtm'].to_i }.max || 0
|
||||
|
||||
rows = []
|
||||
rows << ['Event Name', 'Collector Timestamp', 'Category', 'user_id', 'namespace_id', 'project_id', 'plan']
|
||||
rows << [
|
||||
'Event Name',
|
||||
'Collector Timestamp',
|
||||
'Category',
|
||||
'user_id',
|
||||
'namespace_id',
|
||||
'project_id',
|
||||
'plan',
|
||||
'Label',
|
||||
'Property',
|
||||
'Value'
|
||||
]
|
||||
|
||||
rows << :separator
|
||||
|
||||
events.each do |event|
|
||||
|
|
@ -87,7 +99,10 @@ def generate_snowplow_table
|
|||
standard_context[:user_id],
|
||||
standard_context[:namespace_id],
|
||||
standard_context[:project_id],
|
||||
standard_context[:plan]
|
||||
standard_context[:plan],
|
||||
event['event']['se_label'],
|
||||
event['event']['se_property'],
|
||||
event['event']['se_value']
|
||||
]
|
||||
|
||||
row.map! { |value| red(value) } if event['rawEvent']['parameters']['dtm'].to_i > @initial_max_timestamp
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ module GC::Profiler
|
|||
attr_accessor :use_exclusive
|
||||
|
||||
%i[enable disable clear].each do |method|
|
||||
alias_method "#{method}_orig", "#{method}"
|
||||
alias_method "#{method}_orig", method.to_s
|
||||
|
||||
define_method(method) do
|
||||
if use_exclusive
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ tests.each do |test|
|
|||
next if test['id'] =~ %r{.\/qa\/specs\/features\/sanity\/*}
|
||||
|
||||
if test['testcase']
|
||||
testcases.push(["#{test['testcase']}", "#{test['id']} - #{test['full_description']}"])
|
||||
testcases.push([(test['testcase']).to_s, "#{test['id']} - #{test['full_description']}"])
|
||||
|
||||
unless TESTCASE_FORMAT =~ test['testcase']
|
||||
testcase_format_errors.push(
|
||||
|
|
|
|||
|
|
@ -122,6 +122,56 @@ RSpec.describe Ci::Bridge, feature_category: :continuous_integration do
|
|||
end
|
||||
end
|
||||
|
||||
describe 'state machine events' do
|
||||
describe 'start_cancel!' do
|
||||
valid_statuses = Ci::HasStatus::CANCELABLE_STATUSES.map(&:to_sym) + [:manual]
|
||||
# Invalid statuses are statuses that are COMPLETED_STATUSES or already canceling
|
||||
invalid_statuses = Ci::HasStatus::AVAILABLE_STATUSES.map(&:to_sym) - valid_statuses
|
||||
|
||||
valid_statuses.each do |status|
|
||||
it "transitions from #{status} to canceling" do
|
||||
bridge = create(:ci_bridge, status: status)
|
||||
|
||||
bridge.start_cancel!
|
||||
|
||||
expect(bridge.status).to eq('canceling')
|
||||
end
|
||||
end
|
||||
|
||||
invalid_statuses.each do |status|
|
||||
it "does not transition from #{status} to canceling" do
|
||||
bridge = create(:ci_bridge, status: status)
|
||||
|
||||
expect { bridge.start_cancel! }
|
||||
.to raise_error(StateMachines::InvalidTransition)
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
describe 'finish_cancel!' do
|
||||
valid_statuses = Ci::HasStatus::CANCELABLE_STATUSES.map(&:to_sym) + [:manual, :canceling]
|
||||
invalid_statuses = Ci::HasStatus::AVAILABLE_STATUSES.map(&:to_sym) - valid_statuses
|
||||
valid_statuses.each do |status|
|
||||
it "transitions from #{status} to canceling" do
|
||||
bridge = create(:ci_bridge, status: status)
|
||||
|
||||
bridge.finish_cancel!
|
||||
|
||||
expect(bridge.status).to eq('canceled')
|
||||
end
|
||||
end
|
||||
|
||||
invalid_statuses.each do |status|
|
||||
it "does not transition from #{status} to canceling" do
|
||||
bridge = create(:ci_bridge, status: status)
|
||||
|
||||
expect { bridge.finish_cancel! }
|
||||
.to raise_error(StateMachines::InvalidTransition)
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
describe 'state machine transitions' do
|
||||
context 'when bridge points towards downstream' do
|
||||
%i[created manual].each do |status|
|
||||
|
|
|
|||
|
|
@ -1495,9 +1495,9 @@ RSpec.describe Ci::Pipeline, :mailer, factory_default: :keep, feature_category:
|
|||
let(:build_b) { create_build('build2', queued_at: 0) }
|
||||
let(:build_c) { create_build('build3', queued_at: 0) }
|
||||
|
||||
describe '#canceling' do
|
||||
describe '#start_cancel' do
|
||||
it 'transitions to canceling' do
|
||||
expect { pipeline.canceling }.to change { pipeline.status }.from('created').to('canceling')
|
||||
expect { pipeline.start_cancel }.to change { pipeline.status }.from('created').to('canceling')
|
||||
end
|
||||
end
|
||||
|
||||
|
|
|
|||
|
|
@ -118,13 +118,13 @@ RSpec.describe Ci::Stage, :models, feature_category: :continuous_integration do
|
|||
end
|
||||
end
|
||||
|
||||
describe '#canceling' do
|
||||
describe '#start_cancel' do
|
||||
it 'transitions to canceling' do
|
||||
stage = create(:ci_stage, pipeline: pipeline, project: pipeline.project, status: 'running')
|
||||
create(:ci_build, :success, stage_id: stage.id)
|
||||
create(:ci_build, :running, stage_id: stage.id)
|
||||
|
||||
expect { stage.canceling }.to change { stage.status }.from('running').to('canceling')
|
||||
expect { stage.start_cancel }.to change { stage.status }.from('running').to('canceling')
|
||||
end
|
||||
end
|
||||
|
||||
|
|
|
|||
|
|
@ -1265,17 +1265,18 @@ RSpec.describe Deployment, feature_category: :continuous_delivery do
|
|||
using RSpec::Parameterized::TableSyntax
|
||||
|
||||
where(:status, :method) do
|
||||
'running' | :run!
|
||||
'success' | :succeed!
|
||||
'failed' | :drop!
|
||||
'canceled' | :cancel!
|
||||
'skipped' | :skip!
|
||||
'blocked' | :block!
|
||||
'running' | :run!
|
||||
'success' | :succeed!
|
||||
'failed' | :drop!
|
||||
'canceling' | nil
|
||||
'canceled' | :cancel!
|
||||
'skipped' | :skip!
|
||||
'blocked' | :block!
|
||||
end
|
||||
|
||||
with_them do
|
||||
it 'calls the correct method for the given status' do
|
||||
expect(deploy).to receive(method)
|
||||
expect(deploy).to receive(method) if method
|
||||
|
||||
deploy.update_status(status)
|
||||
end
|
||||
|
|
|
|||
Loading…
Reference in New Issue