diff options
25 files changed, 377 insertions, 117 deletions
diff --git a/app/views/projects/merge_requests/_widget.html.haml b/app/views/projects/merge_requests/_widget.html.haml index 4e69dad2e12..783e3ac97c1 100644 --- a/app/views/projects/merge_requests/_widget.html.haml +++ b/app/views/projects/merge_requests/_widget.html.haml @@ -10,7 +10,7 @@ window.gl.mrWidgetData.squash_before_merge_help_path = '#{help_page_path("user/project/merge_requests/squash_and_merge")}'; window.gl.mrWidgetData.ci_troubleshooting_docs_path = '#{help_page_path('ci/troubleshooting.md')}'; window.gl.mrWidgetData.mr_troubleshooting_docs_path = '#{help_page_path('user/project/merge_requests/reviews/index.md', anchor: 'troubleshooting')}'; - window.gl.mrWidgetData.pipeline_must_succeed_docs_path = '#{help_page_path('user/project/merge_requests/merge_when_pipeline_succeeds.md', anchor: 'only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds')}'; + window.gl.mrWidgetData.pipeline_must_succeed_docs_path = '#{help_page_path('user/project/merge_requests/merge_when_pipeline_succeeds.md', anchor: 'require-a-successful-pipeline-for-merge')}'; window.gl.mrWidgetData.security_approvals_help_page_path = '#{help_page_path('user/application_security/index.md', anchor: 'security-approvals-in-merge-requests')}'; window.gl.mrWidgetData.license_compliance_docs_path = '#{help_page_path('user/compliance/license_compliance/index.md', anchor: 'policies')}'; window.gl.mrWidgetData.eligible_approvers_docs_path = '#{help_page_path('user/project/merge_requests/approvals/rules.md', anchor: 'eligible-approvers')}'; diff --git a/db/fixtures/development/33_triage_ops.rb b/db/fixtures/development/33_triage_ops.rb index b2dd3861169..14832ee4af9 100644 --- a/db/fixtures/development/33_triage_ops.rb +++ b/db/fixtures/development/33_triage_ops.rb @@ -7,6 +7,42 @@ class Gitlab::Seeder::TriageOps WEBHOOK_URL = 'http://0.0.0.0:$PORT$' WEBHOOK_TOKEN = "triage-ops-webhook-token" + WORK_TYPE_LABELS = %w( + bug::availability + bug::mobile + bug::performance + bug::vulnerability + feature::addition + feature::consolidation + feature::enhancement + feature::removal + maintenance::dependency + maintenance::pipelines + maintenance::refactor + maintenance::test-gap + maintenance::usability + maintenance::workflow + type::bug + type::feature + type::maintenance + ) + + WORKFLOW_LABELS = %w( + workflow::blocked + workflow::design + workflow::in dev + workflow::in review + workflow::planning breakdown + workflow::production + workflow::ready + workflow::ready for design + workflow::ready for development + workflow::ready for review + workflow::refinement + workflow::validation backlog + workflow::verification + ) + def seed! puts "Updating settings to allow web hooks to localhost" ApplicationSetting.current_without_cache.update!(allow_local_requests_from_web_hooks_and_services: true) @@ -33,8 +69,12 @@ class Gitlab::Seeder::TriageOps ensure_webhook_for('gitlab-org') puts "Ensuring work type labels" - ensure_work_type_labels_for('gitlab-com') - ensure_work_type_labels_for('gitlab-org') + ensure_labels_for(WORK_TYPE_LABELS, 'gitlab-com') + ensure_labels_for(WORK_TYPE_LABELS, 'gitlab-org') + + puts "Ensuring workflow type labels" + ensure_labels_for(WORKFLOW_LABELS, 'gitlab-com') + ensure_labels_for(WORKFLOW_LABELS, 'gitlab-org') end end end @@ -89,27 +129,7 @@ class Gitlab::Seeder::TriageOps puts "Hook with url '#{hook.url}' and token '#{hook.token}' for '#{group_path}' is present now." end - def ensure_work_type_labels_for(group_path) - label_titles = [ - 'bug::availability', - 'bug::mobile', - 'bug::performance', - 'bug::vulnerability', - 'feature::addition', - 'feature::consolidation', - 'feature::enhancement', - 'feature::removal', - 'maintenance::dependency', - 'maintenance::pipelines', - 'maintenance::refactor', - 'maintenance::test-gap', - 'maintenance::usability', - 'maintenance::workflow', - 'type::bug', - 'type::feature', - 'type::maintenance', - ] - + def ensure_labels_for(label_titles, group_path) group = Group.find_by_full_path(group_path) label_titles.each do |label_title| diff --git a/db/post_migrate/20220901071310_add_tmp_index_user_callouts_on_attention_request_feature_names.rb b/db/post_migrate/20220901071310_add_tmp_index_user_callouts_on_attention_request_feature_names.rb new file mode 100644 index 00000000000..10b339b90c1 --- /dev/null +++ b/db/post_migrate/20220901071310_add_tmp_index_user_callouts_on_attention_request_feature_names.rb @@ -0,0 +1,18 @@ +# frozen_string_literal: true + +class AddTmpIndexUserCalloutsOnAttentionRequestFeatureNames < Gitlab::Database::Migration[2.0] + INDEX_NAME = "tmp_index_user_callouts_on_attention_request_feature_names" + ATTENTION_REQUEST_CALLOUTS = [47, 48] + + disable_ddl_transaction! + + def up + add_concurrent_index :user_callouts, [:id], + where: "feature_name IN (#{ATTENTION_REQUEST_CALLOUTS.join(',')})", + name: INDEX_NAME + end + + def down + remove_concurrent_index_by_name :user_callouts, INDEX_NAME + end +end diff --git a/db/post_migrate/20220901071355_cleanup_attention_request_user_callouts.rb b/db/post_migrate/20220901071355_cleanup_attention_request_user_callouts.rb new file mode 100644 index 00000000000..cbd0d120bb8 --- /dev/null +++ b/db/post_migrate/20220901071355_cleanup_attention_request_user_callouts.rb @@ -0,0 +1,18 @@ +# frozen_string_literal: true +class CleanupAttentionRequestUserCallouts < Gitlab::Database::Migration[2.0] + disable_ddl_transaction! + restrict_gitlab_migration gitlab_schema: :gitlab_main + + ATTENTION_REQUEST_CALLOUTS = [47, 48] + # 47 and 48 were removed with https://gitlab.com/gitlab-org/gitlab/-/merge_requests/95446 + + def up + define_batchable_model('user_callouts') + .where(feature_name: ATTENTION_REQUEST_CALLOUTS) + .each_batch { |batch| batch.delete_all } # rubocop:disable Style/SymbolProc + end + + def down + # Attention request feature has been reverted. + end +end diff --git a/db/schema_migrations/20220901071310 b/db/schema_migrations/20220901071310 new file mode 100644 index 00000000000..9134d6669a0 --- /dev/null +++ b/db/schema_migrations/20220901071310 @@ -0,0 +1 @@ +dee16fbf6edef6da0c9c55b0dca290bc1a1939b8d747ace6594a4d73a70adc7d
\ No newline at end of file diff --git a/db/schema_migrations/20220901071355 b/db/schema_migrations/20220901071355 new file mode 100644 index 00000000000..5e8681b9ff0 --- /dev/null +++ b/db/schema_migrations/20220901071355 @@ -0,0 +1 @@ +3fe94b8d0102c5b5ed7824477cf4a535e42da9a232a320f770442530c77eb960
\ No newline at end of file diff --git a/db/structure.sql b/db/structure.sql index 6723db0147d..5ead436e51a 100644 --- a/db/structure.sql +++ b/db/structure.sql @@ -30795,6 +30795,8 @@ CREATE INDEX tmp_index_project_statistics_cont_registry_size ON project_statisti CREATE INDEX tmp_index_system_note_metadata_on_id_where_task ON system_note_metadata USING btree (id, action) WHERE ((action)::text = 'task'::text); +CREATE INDEX tmp_index_user_callouts_on_attention_request_feature_names ON user_callouts USING btree (id) WHERE (feature_name = ANY (ARRAY[47, 48])); + CREATE INDEX tmp_index_vulnerability_occurrences_on_id_and_scanner_id ON vulnerability_occurrences USING btree (id, scanner_id) WHERE (report_type = ANY (ARRAY[7, 99])); CREATE UNIQUE INDEX uniq_pkgs_deb_grp_architectures_on_distribution_id_and_name ON packages_debian_group_architectures USING btree (distribution_id, name); diff --git a/doc/administration/repository_checks.md b/doc/administration/repository_checks.md index 90944d1b430..691feb47cec 100644 --- a/doc/administration/repository_checks.md +++ b/doc/administration/repository_checks.md @@ -85,3 +85,11 @@ If periodic repository checks cause false alarms, you can clear all repository c 1. On the left sidebar, select **Settings > Repository** (`/admin/application_settings/repository`). 1. Expand the **Repository maintenance** section. 1. Select **Clear all repository checks**. + +### Error: `failed to parse commit <commit SHA> from object database for commit-graph` + +You can see a `failed to parse commit <commit SHA> from object database for commit-graph` error in repository check logs. This error occurs if your `commit-graph` cache is out +of date. The `commit-graph` cache is an auxiliary cache and is not required for regular Git operations. + +While the message can be safely ignored, see the issue [error: Could not read from object database for commit-graph](https://gitlab.com/gitlab-org/gitaly/-/issues/2359) +for more details. diff --git a/doc/api/oauth2.md b/doc/api/oauth2.md index f3ad1f8082f..0b7e0ba08eb 100644 --- a/doc/api/oauth2.md +++ b/doc/api/oauth2.md @@ -354,7 +354,11 @@ curl --header "Authorization: Bearer OAUTH-TOKEN" "https://gitlab.example.com/ap A token with [scope](../integration/oauth_provider.md#authorized-applications) `read_repository` or `write_repository` can access Git over HTTPS. Use the token as the password. -The username must be `oauth2`, not your username. +The username must be `oauth2`, not your username: + +```plaintext +https://oauth2:<your_access_token>@gitlab.example.com/project_path/project_name.git +``` ## Retrieve the token information diff --git a/doc/api/projects.md b/doc/api/projects.md index 926d823c012..26733801b45 100644 --- a/doc/api/projects.md +++ b/doc/api/projects.md @@ -1223,7 +1223,7 @@ curl --request POST --header "PRIVATE-TOKEN: <your-token>" \ | `mirror` **(PREMIUM)** | boolean | **{dotted-circle}** No | Enables pull mirroring in a project. | | `namespace_id` | integer | **{dotted-circle}** No | Namespace for the new project (defaults to the current user's namespace). | | `only_allow_merge_if_all_discussions_are_resolved` | boolean | **{dotted-circle}** No | Set whether merge requests can only be merged when all the discussions are resolved. | -| `only_allow_merge_if_pipeline_succeeds` | boolean | **{dotted-circle}** 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#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds) in the project settings. | +| `only_allow_merge_if_pipeline_succeeds` | boolean | **{dotted-circle}** 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. | | `operations_access_level` | string | **{dotted-circle}** No | One of `disabled`, `private`, or `enabled`. | | `packages_enabled` | boolean | **{dotted-circle}** No | Enable or disable packages repository feature. | | `pages_access_level` | string | **{dotted-circle}** No | One of `disabled`, `private`, `enabled`, or `public`. | diff --git a/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md b/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md index a70a01031a7..baec14e3f0f 100644 --- a/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md +++ b/doc/architecture/blueprints/ci_data_decay/pipeline_partitioning.md @@ -76,8 +76,8 @@ to notify us when this number is exceeded. Large SQL tables increase index maintenance time, during which freshly deleted tuples cannot be cleaned by `autovacuum`. This highlight the need for small tables. -We will measure how much bloat we accumulate when [re]indexing huge tables. Base on this analysis, -we will be able to set up SLO (dead tuples / bloat), associated with [re]indexing. +We will measure how much bloat we accumulate when (re)indexing huge tables. Base on this analysis, +we will be able to set up SLO (dead tuples / bloat), associated with (re)indexing. We've seen numerous S1 and S2 database-related production environment incidents, over the last couple of months, for example: diff --git a/doc/architecture/blueprints/pods/index.md b/doc/architecture/blueprints/pods/index.md new file mode 100644 index 00000000000..e4470407b40 --- /dev/null +++ b/doc/architecture/blueprints/pods/index.md @@ -0,0 +1,162 @@ +--- +stage: enablement +group: pods +comments: false +description: 'Pods' +--- + +# Pods + +DISCLAIMER: +This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc. + +This document is a work-in-progress and represents a very early state of the Pods design. Significant aspects are not documented, though we expect to add them in the future. + +## Summary + +Pods is a new architecture for our Software as a Service platform that is horizontally-scalable, resilient, and provides a more consistent user experience. It may also provide additional features in the future, such as data residency control (regions) and federated features. + +## Terminology + +We use the following terms to describe components and properties of the Pods architecture. + +### Pod + +A Pod is a set of infrastructure components that contains multiple workspaces that belong to different organizations. The components include both datastores (PostgreSQL, Redis etc.) and stateless services (web etc.). The infrastructure components provided within a Pod are shared among workspaces but not shared with other Pods. This isolation of infrastructure components means that Pods are independent from each other. + +#### Pod properties + +- Each pod is independent from the others +- Infrastructure components are shared by workspaces within a Pod +- More Pods can be provisioned to provide horizontal scalability +- A failing Pod does not lead to failure of other Pods +- Noisy neighbor effects are limited to within a Pod +- Pods are not visible to organizations; it is an implementation detail + +Discouraged synonyms: GitLab instance, cluster, shard + +### Organization + +An [Organization](../../../topics/set_up_organization.md) is an entity representing a billable account or customer. GitLab has no internal object representing an organization. Instead, organizations map to a single workspace. + +Discouraged synonyms: Customers, Accounts, Billable entity + +#### Organization properties + +- Organizations are located on a single Pod +- Organizations can create only one workspace + +### Workspace + +A [workspace](../../../user/workspace/index.md) is the name for the top-level namespace that is used by organizations to manage everything GitLab. It will provide similar administrative capabilities to a self-managed instance. + +See more in the [workspace group overview](https://about.gitlab.com/direction/manage/workspace/#overview). + +#### Workspace properties + +- Workspaces are isolated from each other by default +- A workspace is located on a single Pod +- Workspaces share the resources provided by a Pod + +### Top-Level namespace + +A top-level namespace is the logical object container in the code that represents all groups, subgroups and projects that belong to an organization. + +A top-level namespace is the root of nested collection namespaces and projects. The namespace and its related entities form a tree-like hierarchy: Namespaces are the nodes of the tree, projects are the leaves. An organization usually contains a single top-level namespace, called a workspace. + +Example: + +`https://gitlab.com/gitlab-org/gitlab/`: + +- `gitlab-org` is a `top-level namespace`; the root for all groups and projects of an organization +- `gitlab` is a `project`; a project of the organization. + +Discouraged synonyms: Root-level namespace + +#### Top-level namespace properties + +Same as workspaces. + +## Goals + +### Scalability + +The main goal of this new shared-infrastructure architecture is to provide additional scalability for our SaaS Platform. GitLab.com is largely monolithic and we have estimated (internal) that the current architecture has scalability limitations, even when database partitioning and decomposition are taken into account. + +Pods provide a horizontally scalable solution because additional Pods can be created based on demand. Pods can be provisioned and tuned as needed for optimal scalability. + +### Increased availability + +A major challenge for shared-infrastructure architectures is a lack of isolation between workspaces. This can lead to noisy neighbor effects. A organization's behavior inside a workspace can impact all other workspaces. This is highly undesirable. Pods provide isolation at the pod level. A group of organizations is fully isolated from other organizations located on a different Pod. This minimizes noisy neighbor effects while still benefiting from the cost-efficiency of shared infrastructure. + +Additionally, Pods provide a way to implement disaster recovery capabilities. Entire Pods may be replicated to read-only standbys with automatic failover capabilities. + +### A consistent experience + +Organizations should have the same user experience on our SaaS platform as they do on a self-managed GitLab instance. + +### Regions + +GitLab.com is only hosted within the United States of America. Organizations located in other regions have voiced demand for local SaaS offerings. Pods provide a path towards [GitLab Regions](https://gitlab.com/groups/gitlab-org/-/epics/6037) because Pods may be deployed within different geographies. Depending on which of the organization's data is located outside a Pod, this may solve data residency and compliance problems. + +## Market segment + +Pods would provide a solution for organizations in the small to medium business (up to 100 users) and the mid-market segment (up to 2000 users). +(See [segmentation definitions](https://about.gitlab.com/handbook/sales/field-operations/gtm-resources/#segmentation).) +Larger organizations may benefit substantially from [GitLab Dedicated](../../../subscriptions/gitlab_dedicated/index.md). + +## High-level architecture problems to solve + +A number of technical issues need to be resolved to implement Pods (in no particular order). This section will be expanded. + +1. How are users of an organization routed to the correct Pod containing their workspace? +1. How do users authenticate? +1. How are Pods rebalanced? +1. How are Pods provisioned? +1. How can Pods implement disaster recovery capabilities? + +## Iteration 1 + +Ultimately, a Pods architecture should offer the same user experience as self-managed and GitLab dedicated. However, at this moment GitLab.com has many more "social-network"-like capabilities that will be difficult to implement with a Pods architecture. We should evaluate if the SMB and mid market segment is interested in these features, or if not having them is acceptable in most cases. + +The first iteration of Pods will still contain some limitations that would break cross-workspace workflows. This means it may only be acceptable for new customers, or for existing customers that are briefed. + +Limitations are: + +- An organization can create only a single workspace. +- Workspaces are isolated from each other. This means cross-workspace workflows are broken. + +## Iteration 2 + +Based on user research, we may want to change certain features to work across namespaces to allow organizations to interact with each other in specific circumstances. We may also allow organizations to have more than one workspace. This is particularly relevant for organizations with sub-divisions, or multi-national organizations that want to have workspaces in different regions. + +Additional features: + +- Specific features allow for cross-workspace interactions, for example forking, search. +- An organization can own multiple workspaces on different Pods. + +### Links + +- [Internal Pods presentation](https://docs.google.com/presentation/d/1x1uIiN8FR9fhL7pzFh9juHOVcSxEY7d2_q4uiKKGD44/edit#slide=id.ge7acbdc97a_0_155) +- [Pods Epic](https://gitlab.com/groups/gitlab-org/-/epics/7582) +- [Database Group investigation](https://about.gitlab.com/handbook/engineering/development/enablement/data_stores/database/doc/root-namespace-sharding.html) +- [Shopify Pods architecture](https://shopify.engineering/a-pods-architecture-to-allow-shopify-to-scale) +- [Opstrace architecture](https://gitlab.com/gitlab-org/opstrace/opstrace/-/blob/main/docs/architecture/overview.md) + +### Who + +| Role | Who +|------------------------------|-------------------------| +| Author | Fabian Zimmer | +| Architecture Evolution Coach | Kamil Trzciński | +| Engineering Leader | TBD | +| Product Manager | Fabian Zimmer | +| Domain Expert / Database | TBD | + +DRIs: + +| Role | Who +|------------------------------|------------------------| +| Leadership | TBD | +| Product | Fabian Zimmer | +| Engineering | Thong Kuah | diff --git a/doc/ci/pipelines/merge_trains.md b/doc/ci/pipelines/merge_trains.md index 70a0d177ac6..8ff22bfa990 100644 --- a/doc/ci/pipelines/merge_trains.md +++ b/doc/ci/pipelines/merge_trains.md @@ -209,7 +209,7 @@ If it succeeds after a retry, the merge request is not removed from the merge tr Sometimes the **Start/Add to merge train** button is not available and the merge request says, "The pipeline for this merge request failed. Please retry the job or push a new commit to fix the failure." -This issue occurs when [**Pipelines must succeed**](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds) +This issue occurs when [**Pipelines must succeed**](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge) is enabled in **Settings > General > Merge requests**. This option requires that you run a new successful pipeline before you can re-add a merge request to a merge train. diff --git a/doc/ci/troubleshooting.md b/doc/ci/troubleshooting.md index 33dc77c45a9..78b48c11f98 100644 --- a/doc/ci/troubleshooting.md +++ b/doc/ci/troubleshooting.md @@ -259,7 +259,7 @@ are enabled, the button is either **Add to merge train** or **Add to merge train #### "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#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds) +This message is shown if the [Pipelines must succeed](../user/project/merge_requests/merge_when_pipeline_succeeds.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. If you don't use pipelines for your project, then you diff --git a/doc/ci/yaml/index.md b/doc/ci/yaml/index.md index e8ab13e1608..65955b3e4e0 100644 --- a/doc/ci/yaml/index.md +++ b/doc/ci/yaml/index.md @@ -2622,7 +2622,7 @@ docker build: **Related topics**: - [`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), +- 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#require-a-successful-pipeline-for-merge), 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). diff --git a/doc/ci/yaml/workflow.md b/doc/ci/yaml/workflow.md index 743a2639c0c..d3e815c742d 100644 --- a/doc/ci/yaml/workflow.md +++ b/doc/ci/yaml/workflow.md @@ -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#only-allow-merge-requests-to-be-merged-if-the-pipeline-succeeds) +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) 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 diff --git a/doc/development/service_ping/implement.md b/doc/development/service_ping/implement.md index 4ef58fefcb9..3d88c2a6718 100644 --- a/doc/development/service_ping/implement.md +++ b/doc/development/service_ping/implement.md @@ -382,7 +382,7 @@ Implemented using Redis methods [PFADD](https://redis.io/commands/pfadd/) and [P - `controller_actions`: the controller actions to track. - `name`: the event name. - `conditions`: optional custom conditions. Uses the same format as Rails callbacks. - - `destinations`: optional list of destinations. Currently supports `:redis_hll` and `:snowplow`. Default: [:redis_hll]. + - `destinations`: optional list of destinations. Currently supports `:redis_hll` and `:snowplow`. Default: `:redis_hll`. - `&block`: optional block that computes and returns the `custom_id` that we want to track. This overrides the `visitor_id`. Example: diff --git a/doc/integration/saml.md b/doc/integration/saml.md index eb33770c4af..29e65fdf4d9 100644 --- a/doc/integration/saml.md +++ b/doc/integration/saml.md @@ -873,7 +873,7 @@ is available. If you only require a SAML provider for testing, a [quick start guide to start a Docker container](../administration/troubleshooting/test_environments.md#saml) with a plug and play SAML 2.0 Identity Provider (IdP) is available. -### "undefined method [] for nil:NilClass" exception on groups page +### `undefined method [] for nil:NilClass` exception on groups page On GitLab 14.6 and newer, you can see the `undefined method [] for nil:NilClass` error if you have not configured at least one SAML provider with the name `saml`. This error is caused by a [known issue](https://gitlab.com/gitlab-org/gitlab/-/issues/366450). To resolve this error, ensure that at least one SAML provider has the name `saml`. diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md index 2152ca39e5a..9bb79b5cc90 100644 --- a/doc/user/gitlab_com/index.md +++ b/doc/user/gitlab_com/index.md @@ -328,6 +328,12 @@ for `shared_buffers` is quite high, and we are GitLab.com uses the default of 60 seconds for [Puma request timeouts](../../administration/operations/puma.md#change-the-worker-timeout). +## Merge request reviewer maximum + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91406) in GitLab 15.3. + +A maximum of 100 reviewers can be assigned to a merge request. + ## GitLab.com-specific rate limits NOTE: diff --git a/doc/user/project/merge_requests/img/cancel-mwps_v15_4.png b/doc/user/project/merge_requests/img/cancel-mwps_v15_4.png Binary files differnew file mode 100644 index 00000000000..7ed780d4389 --- /dev/null +++ b/doc/user/project/merge_requests/img/cancel-mwps_v15_4.png diff --git a/doc/user/project/merge_requests/img/merge_when_pipeline_succeeds_enable.png b/doc/user/project/merge_requests/img/merge_when_pipeline_succeeds_enable.png Binary files differdeleted file mode 100644 index 9487264b41a..00000000000 --- a/doc/user/project/merge_requests/img/merge_when_pipeline_succeeds_enable.png +++ /dev/null diff --git a/doc/user/project/merge_requests/img/merge_when_pipeline_succeeds_status.png b/doc/user/project/merge_requests/img/merge_when_pipeline_succeeds_status.png Binary files differdeleted file mode 100644 index 70fa2efc855..00000000000 --- a/doc/user/project/merge_requests/img/merge_when_pipeline_succeeds_status.png +++ /dev/null diff --git a/doc/user/project/merge_requests/img/mwps_v15_4.png b/doc/user/project/merge_requests/img/mwps_v15_4.png Binary files differnew file mode 100644 index 00000000000..f042912d470 --- /dev/null +++ b/doc/user/project/merge_requests/img/mwps_v15_4.png diff --git a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md index c1b85bb4acc..6aac57ad144 100644 --- a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md +++ b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md @@ -7,123 +7,143 @@ type: reference, concepts # Merge when pipeline succeeds **(FREE)** -When reviewing a merge request that looks ready to merge but still has a -pipeline running, you can set it to merge automatically when the -pipeline succeeds. This way, you don't have to wait for the pipeline to -finish and remember to merge the request manually. +If you review a merge request and it's ready to merge, but the pipeline hasn't +completed yet, you can set it to merge when the pipeline succeeds (MWPS). You don't +have to remember later to merge the work manually: - + -## How it works +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: -When you select "Merge When Pipeline Succeeds", the status of the merge -request is updated to show the impending merge. If you can't wait -for the pipeline to succeed, you can choose **Merge immediately** -in the dropdown menu on the right of the main button. +- 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 MWPS request + to ensure the new changes are reviewed before merge. -The author of the merge request and project members with the Developer role can -cancel the automatic merge at any time before the pipeline finishes. +## Set a merge request to MWPS - +Prerequisites: -When the pipeline succeeds, the merge request is automatically merged. -When the pipeline fails, the author gets a chance to retry any failed jobs, -or to push new commits to fix the failure. +- 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](../../discussions/index.md#resolve-a-thread). +- The merge request must have received all required approvals. -When the jobs are retried and succeed on the second try, the merge request -is automatically merged. When the merge request is updated with -new commits, the automatic merge is canceled to allow the new -changes to be reviewed. +To do this when pushing from the command line, use the `merge_request.merge_when_pipeline_succeeds` +[push option](../push_options.md). -By default, all threads must be resolved before you see the **Merge when -pipeline succeeds** button. If someone adds a new comment after -the button is selected, but before the jobs in the CI pipeline are -complete, the merge is blocked until you resolve all existing threads. +To do this from the GitLab user interface: -## Only allow merge requests to be merged if the pipeline succeeds +1. On the top bar, select **Menu > Projects** and find your project. +1. On the left sidebar, select **Merge requests**. +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 **Merge when pipeline succeeds**. + +If a new comment is added to the merge request after you select **Merge when pipeline succeeds**, +but before the pipeline completes, GitLab blocks the merge until you +resolve all existing threads. + +## Cancel an auto-merge + +If a merge request is set to MWPS, you can cancel it. + +Prerequisites: -You can prevent merge requests from being merged if: +- 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. -- No pipeline ran. -- The pipeline did not succeed. +To do this: -This works for both: +1. On the top bar, select **Menu > Projects** and find your project. +1. On the left sidebar, select **Merge requests**. +1. Scroll to the merge request reports section. +1. Select **Cancel auto-merge**. + + + +## Require a successful pipeline for merge -- GitLab CI/CD pipelines -- Pipelines run from an [external CI integration](../integrations/index.md#available-integrations) +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/enable_or_disable_ci.md) -does not disable this feature, as it is possible to use pipelines from external -CI providers with this feature. To enable it, you must: +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 top bar, select **Menu > Projects** and find your project. 1. On the left sidebar, select **Settings > Merge requests**. -1. In the **Merge checks** section, select **Pipelines must succeed**. +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-requests-dont-merge-when-successful-pipeline-is-required). 1. Select **Save**. -This setting also prevents merge requests from being merged if there is no pipeline. -You should be careful to configure CI/CD so that pipelines run for every merge request. +### Allow merge after skipped pipelines + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211482) in GitLab 13.1. + +When the **Pipelines must succeed** checkbox is checked, +[skipped pipelines](../../../ci/pipelines/index.md#skip-a-pipeline) prevent +merge requests from being merged. -### Limitations +Prerequisite: -When this setting is enabled, a merge request is prevented from being merged if there -is no pipeline. This may conflict with some use cases where [`only/except`](../../../ci/yaml/index.md#only--except) -or [`rules`](../../../ci/yaml/index.md#rules) are used and they don't generate any pipelines. +- You must have at least the Maintainer role in the project. -You should ensure that [there is always a pipeline](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/54226) -and that it's successful. +To change this behavior: + +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. Under **Merge checks**: + - Select **Pipelines must succeed**. + - Select **Skipped pipelines are considered successful**. +1. Select **Save**. -If both a branch pipeline and a merge request pipeline are triggered for a single -merge request, only the success or failure of the *merge request pipeline* is checked. -If the merge request pipeline is configured with fewer jobs than the branch pipeline, -it could allow code that fails tests to be merged: +## Troubleshooting + +### Merge requests don't merge when successful pipeline is required + +If you require a successful pipeline for a merge, this setting can conflict with some +use cases that do not generate pipelines, such as [`only/except`](../../../ci/yaml/index.md#only--except) +or [`rules`](../../../ci/yaml/index.md#rules). Ensure your project +[runs a pipeline](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/54226) for +every merge request, and that the pipeline is successful. + +### Ensure test parity between pipeline types + +If a merge request triggers both a branch pipeline and a merge request pipeline, +the success or failure of only the *merge request pipeline* is checked. +If the merge request pipeline contains fewer jobs than the branch pipeline, +it could allow code that fails tests to be merged, like in this example: ```yaml branch-pipeline-job: rules: - if: $CI_PIPELINE_SOURCE == "push" script: - - echo "Code testing scripts here, for example." + - echo "Testing happens here." merge-request-pipeline-job: rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event" script: - - echo "No tests run, but this pipeline always succeeds and enables merge." + - echo "No testing happens here. This pipeline always succeeds, and enables merge." - echo true ``` -You should avoid configuration like this, and only use branch (`push`) pipelines -or merge request pipelines, when possible. See [`rules` documentation](../../../ci/jobs/job_control.md#avoid-duplicate-pipelines) -for details on avoiding two pipelines for a single merge request. - -### Skipped pipelines - -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211482) in GitLab 13.1. - -When the **Pipelines must succeed** checkbox is checked, [skipped pipelines](../../../ci/pipelines/index.md#skip-a-pipeline) prevent -merge requests from being merged. To change this behavior: - -1. On the top bar, select **Menu > Projects** and find your project. -1. On the left sidebar, select **Settings > Merge requests**. -1. In the **Merge checks** section: - - Ensure **Pipelines must succeed** is selected. - - Select **Skipped pipelines are considered successful**. -1. Select **Save**. - -## From the command line - -You can use [Push Options](../push_options.md) to enable merge when pipeline succeeds -for a merge request when pushing from the command line. - -<!-- ## Troubleshooting - -Include any troubleshooting steps that you can foresee. If you know beforehand what issues -one might have when setting this up, or when something is changed, or on upgrading, it's -important to describe those, too. Think of things that may go wrong and include them here. -This is important to minimize requests for support, and to avoid doc comments with -questions that you know someone might ask. - -Each scenario can be a third-level heading, e.g. `### Getting error message X`. -If you have none to add when creating a doc, leave this section in place -but commented out to help encourage others to add to it in the future. --> +Instead, use branch (`push`) pipelines or merge request pipelines, when possible. +For details on avoiding two pipelines for a single merge request, read the +[`rules` documentation](../../../ci/jobs/job_control.md#avoid-duplicate-pipelines). diff --git a/doc/user/project/merge_requests/reviews/index.md b/doc/user/project/merge_requests/reviews/index.md index 5a788f595ea..78f82b019b8 100644 --- a/doc/user/project/merge_requests/reviews/index.md +++ b/doc/user/project/merge_requests/reviews/index.md @@ -96,7 +96,7 @@ If you have a review in progress, you can also add a comment from the **Overview ### Approval Rule information for Reviewers **(PREMIUM)** > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/233736) in GitLab 13.8. -> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/293742) in GitLab 13.9. +> - [Feature flag `reviewer_approval_rules` removed](https://gitlab.com/gitlab-org/gitlab/-/issues/293742) in GitLab 13.9. When editing the **Reviewers** field in a new or existing merge request, GitLab displays the name of the matching [approval rule](../approvals/rules.md) |
