Add latest changes from gitlab-org/gitlab@master

9 files changed, 203 insertions, 112 deletions

diff --git a/app/services/commits/change_service.rb b/app/services/commits/change_service.rb
index dc7f84ab807..0b97aae9972 100644
--- a/app/services/commits/change_service.rb
+++ b/app/services/commits/change_service.rb
@@ -29,12 +29,24 @@ module Commits
         dry_run: @dry_run
       )
     rescue Gitlab::Git::Repository::CreateTreeError => ex
-      act = action.to_s.dasherize
       type = @commit.change_type_title(current_user)
 
-      error_msg = "Sorry, we cannot #{act} this #{type} automatically. " \
-        "This #{type} may already have been #{act}ed, or a more recent " \
-        "commit may have updated some of its content."
+      status = case [type, action]
+               when ['commit', :cherry_pick]
+                 s_("MergeRequests|Commit cherry-pick failed")
+               when ['commit', :revert]
+                 s_("MergeRequests|Commit revert failed")
+               when ['merge request', :cherry_pick]
+                 s_("MergeRequests|Merge request cherry-pick failed")
+               when ['merge request', :revert]
+                 s_("MergeRequests|Merge request revert failed")
+               end
+
+      detail = s_("MergeRequests|Can't perform this action automatically. " \
+        "It may have already been done, or a more recent commit may have updated some of this content. " \
+        "Please perform this action locally.")
+
+      error_msg = "#{status}: #{detail}"
 
       raise ChangeError.new(error_msg, ex.error_code)
     end
diff --git a/app/workers/new_merge_request_worker.rb b/app/workers/new_merge_request_worker.rb
index a32a414c0ba..74239c5d968 100644
--- a/app/workers/new_merge_request_worker.rb
+++ b/app/workers/new_merge_request_worker.rb
@@ -18,7 +18,6 @@ class NewMergeRequestWorker # rubocop:disable Scalability/IdempotentWorker
 
   def perform(merge_request_id, user_id)
     return unless objects_found?(merge_request_id, user_id)
-    return if issuable.prepared?
 
     MergeRequests::AfterCreateService
       .new(project: issuable.target_project, current_user: user)
diff --git a/doc/architecture/blueprints/pods/index.md b/doc/architecture/blueprints/pods/index.md
index 077303be30f..17584d010be 100644
--- a/doc/architecture/blueprints/pods/index.md
+++ b/doc/architecture/blueprints/pods/index.md
@@ -8,39 +8,41 @@ owning-stage: "~devops::enablement"
 participating-stages: []
 ---
 
-# Pods
+# Cells
 
-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.
+This document is a work-in-progress and represents a very early state of the Cells 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.
+Cells 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.
+We use the following terms to describe components and properties of the Cells architecture.
 
-### Pod
+### Cell
 
-A Pod is a set of infrastructure components that contains multiple top-level namespaces 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 organizations and their top-level namespaces but not shared with other Pods. This isolation of infrastructure components means that Pods are independent from each other.
+> Pod was renamed to Cell in <https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/121163>
 
-![Term Pod](images/term-pod.png)
+A Cell is a set of infrastructure components that contains multiple top-level namespaces that belong to different organizations. The components include both datastores (PostgreSQL, Redis etc.) and stateless services (web etc.). The infrastructure components provided within a Cell are shared among organizations and their top-level namespaces but not shared with other Cells. This isolation of infrastructure components means that Cells are independent from each other.
 
-#### Pod properties
+![Term Cell](images/term-pod.png)
 
-- Each pod is independent from the others
-- Infrastructure components are shared by organizations and their top-level namespaces 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
-- Pods may be located in different geographical regions (for example, EU, US, JP, UK)
+#### Cell properties
+
+- Each cell is independent from the others
+- Infrastructure components are shared by organizations and their top-level namespaces within a Cell
+- More Cells can be provisioned to provide horizontal scalability
+- A failing Cell does not lead to failure of other Cells
+- Noisy neighbor effects are limited to within a Cell
+- Cells are not visible to organizations; it is an implementation detail
+- Cells may be located in different geographical regions (for example, EU, US, JP, UK)
 
 Discouraged synonyms: GitLab instance, cluster, shard
 
 ### Cluster
 
-A cluster is a collection of Pods.
+A cluster is a collection of Cells.
 
 ![Term Cluster](images/term-cluster.png)
 
@@ -54,7 +56,7 @@ Discouraged synonyms: whale
 
 GitLab references [Organizations in the initial set up](../../../topics/set_up_organization.md) and users can add a (free text) organization to their profile. There is no Organization entity established in the GitLab codebase.
 
-As part of delivering Pods, we propose the introduction of an `organization` entity. Organizations would represent billable entities or customers.
+As part of delivering Cells, we propose the introduction of an `organization` entity. Organizations would represent billable entities or customers.
 
 Organizations are a known concept, present for example in [AWS](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/core-concepts.html) and [GCP](https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy#organizations).
 
@@ -64,7 +66,7 @@ Organizations work under the following assumptions:
 1. Features need to work within an organization.
 1. Only few features need to work across organizations.
 1. Users understand that the majority of pages they view are only scoped to a single organization at a time.
-1. Organizations are located on a single pod.
+1. Organizations are located on a single cell.
 
 ![Term Organization](images/term-organization.png)
 
@@ -98,16 +100,16 @@ Discouraged synonyms: Root-level namespace
 
 #### Top-level namespace properties
 
-- Top-level namespaces belonging to an organization are located on the same Pod
+- Top-level namespaces belonging to an organization are located on the same Cell
 - Top-level namespaces can interact with other top-level namespaces that belong to the same organization
 
 ### Users
 
-Users are available globally and not restricted to a single Pod. Users can be members of many different organizations with varying permissions. Inside organizations, users can create multiple top-level namespaces. User activity is not limited to a single organization but their contributions (for example TODOs) are only aggregated within an organization. This avoids the need for aggregating across pods.
+Users are available globally and not restricted to a single Cell. Users can be members of many different organizations with varying permissions. Inside organizations, users can create multiple top-level namespaces. User activity is not limited to a single organization but their contributions (for example TODOs) are only aggregated within an organization. This avoids the need for aggregating across cells.
 
 #### User properties
 
-- Users are shared globally across all Pods
+- Users are shared globally across all Cells
 - Users can create multiple top-level namespaces
 - Users can be a member of multiple top-level namespaces
 - Users can be a member of multiple organizations
@@ -121,13 +123,13 @@ Users are available globally and not restricted to a single Pod. Users can be me
 
 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.
+Cells provide a horizontally scalable solution because additional Cells can be created based on demand. Cells 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 top-level namespaces. This can lead to noisy neighbor effects. A organization's behavior inside a top-level namespace can impact all other organizations. 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.
+A major challenge for shared-infrastructure architectures is a lack of isolation between top-level namespaces. This can lead to noisy neighbor effects. A organization's behavior inside a top-level namespace can impact all other organizations. This is highly undesirable. Cells provide isolation at the cell level. A group of organizations is fully isolated from other organizations located on a different Cell. 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.
+Additionally, Cells provide a way to implement disaster recovery capabilities. Entire Cells may be replicated to read-only standbys with automatic failover capabilities.
 
 ### A consistent experience
 
@@ -135,11 +137,11 @@ Organizations should have the same user experience on our SaaS platform as they
 
 ### 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.
+GitLab.com is only hosted within the United States of America. Organizations located in other regions have voiced demand for local SaaS offerings. Cells provide a path towards [GitLab Regions](https://gitlab.com/groups/gitlab-org/-/epics/6037) because Cells may be deployed within different geographies. Depending on which of the organization's data is located outside a Cell, 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).
+Cells 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).
 
@@ -153,36 +155,36 @@ We should evaluate if the SMB and mid market segment is interested in these feat
 ### Self-managed
 
 For reasons of consistency, it is expected that self-managed instances will
-adopt the pods architecture as well. To expand, self-managed instances can
-continue with just a single Pod while supporting the option of adding additional
-Pods. Organizations, and possible User decomposition will also be adopted for
+adopt the cells architecture as well. To expand, self-managed instances can
+continue with just a single Cell while supporting the option of adding additional
+Cells. Organizations, and possible User decomposition will also be adopted for
 self-managed instances.
 
 ## 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.
+A number of technical issues need to be resolved to implement Cells (in no particular order). This section will be expanded.
 
-1. How are users of an organization routed to the correct Pod?
+1. How are users of an organization routed to the correct Cell?
 1. How do users authenticate?
-1. How are Pods rebalanced?
-1. How are Pods provisioned?
-1. How can Pods implement disaster recovery capabilities?
+1. How are Cells rebalanced?
+1. How are Cells provisioned?
+1. How can Cells implement disaster recovery capabilities?
 
 ## Cross-section impact
 
-Pods is a fundamental architecture change that impacts other sections and stages. This section summarizes and links to other groups that may be impacted and highlights potential conflicts that need to be resolved. The Pods group is not responsible for achieving the goals of other groups but we want to ensure that dependencies are resolved.
+Cells is a fundamental architecture change that impacts other sections and stages. This section summarizes and links to other groups that may be impacted and highlights potential conflicts that need to be resolved. The Pods group is not responsible for achieving the goals of other groups but we want to ensure that dependencies are resolved.
 
 ### Summary
 
-Based on discussions with other groups the net impact of introducing Pods and a new entity called organizations is mostly neutral. It may slow down development in some areas. We did not discover major blockers for other teams.
+Based on discussions with other groups the net impact of introducing Cells and a new entity called organizations is mostly neutral. It may slow down development in some areas. We did not discover major blockers for other teams.
 
 1. We need to resolve naming conflicts (proposal is TBD)
-1. Pods requires introducing Organizations. Organizations are a new entity **above** top-level groups. Because this is a new entity, it may impact the ability to consolidate settings for Group Workspace and influence their decision on [how to approach introducing a workspace](https://gitlab.com/gitlab-org/gitlab/-/issues/376285#approach-2-workspace-is-built-on-top-of-top-level-groups)
+1. Cells requires introducing Organizations. Organizations are a new entity **above** top-level groups. Because this is a new entity, it may impact the ability to consolidate settings for Group Workspace and influence their decision on [how to approach introducing a workspace](https://gitlab.com/gitlab-org/gitlab/-/issues/376285#approach-2-workspace-is-built-on-top-of-top-level-groups)
 1. Organizations may make it slightly easier for Fulfillment to realize their billing plans.
 
 ### Impact on Group Manage Workspace
 
-We synced with the Workspace PM and Designer ([recording](https://youtu.be/b5Opn9cFWFk)) and discussed the similarities and differences between the Pods and Workspace proposal ([presentation](https://docs.google.com/presentation/d/1FsUi22Up15b_tu6p2m-yLML3hCZ3rgrZrmzJAxUsNmU/edit?usp=sharing)).
+We synced with the Workspace PM and Designer ([recording](https://youtu.be/b5Opn9cFWFk)) and discussed the similarities and differences between the Cells and Workspace proposal ([presentation](https://docs.google.com/presentation/d/1FsUi22Up15b_tu6p2m-yLML3hCZ3rgrZrmzJAxUsNmU/edit?usp=sharing)).
 
 #### Goals of Group Manage Workspace
 
@@ -195,7 +197,7 @@ As defined in the [workspace documentation](../../../user/workspace/index.md):
 
 The [workspace roadmap outlines](https://gitlab.com/gitlab-org/gitlab/-/issues/368237#high-level-goals) the current goals in detail.
 
-#### Potential conflicts with Pods
+#### Potential conflicts with Cells
 
 - Workspace and Organization are different terms for the same entity. Both define a new entity as the primary organizational object for groups and projects. This is mainly a semantic difference and **we need to decide on a name** following [user research to decide if workspace](https://gitlab.com/gitlab-org/ux-research/-/issues/2147). This is also driven by the fact that the Remote Development team is looking at better names and [are considering the term Workspace as well](https://gitlab.com/gitlab-com/Product/-/issues/4812).
 - We will only introduce one entity
@@ -203,7 +205,7 @@ The [workspace roadmap outlines](https://gitlab.com/gitlab-org/gitlab/-/issues/3
 
 ### Impact on Fulfillment
 
-We synced with Fulfillment ([recording](https://youtu.be/FkQF3uF7vTY)) to discuss how Pods would impact them. Fulfillment is supportive of an entity above top-level namespaces. Their perspective is outline in [!5639](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5639/diffs).
+We synced with Fulfillment ([recording](https://youtu.be/FkQF3uF7vTY)) to discuss how Cells would impact them. Fulfillment is supportive of an entity above top-level namespaces. Their perspective is outline in [!5639](https://gitlab.com/gitlab-org/customers-gitlab-com/-/merge_requests/5639/diffs).
 
 #### Goals of Fulfillment
 
@@ -215,30 +217,30 @@ We synced with Fulfillment ([recording](https://youtu.be/FkQF3uF7vTY)) to discus
 
 A rough representation of this is:
 
-![Pods and Fulfillment](images/pods-and-fulfillment.png)
+![Cells and Fulfillment](images/pods-and-fulfillment.png)
 
-#### Potential conflicts with Pods
+#### Potential conflicts with Cells
 
-- There are no known conflicts between Fulfillment's plans and Pods
+- There are no known conflicts between Fulfillment's plans and Cells
 
 ## Iteration plan
 
-We can't ship the entire Pods architecture in one go - it is too large. Instead, we are adopting an iteration plan that provides value along the way.
+We can't ship the entire Cells architecture in one go - it is too large. Instead, we are adopting an iteration plan that provides value along the way.
 
 1. Introduce organizations
 1. Migrate existing top-level namespaces to organizations
-1. Create new organizations on `pod_0`
-1. Migrate existing organizations from `pod_0` to `pod_n`
-1. Add additional Pod capabilities (DR, Regions)
+1. Create new organizations on `cell`
+1. Migrate existing organizations from `cell` to `cell`
+1. Add additional Cell capabilities (DR, Regions)
 
 ### Iteration 0: Introduce organizations
 
 In the first iteration, we introduce the concept of an organization
-as a way to group top-level namespaces together. Support for organizations **does not require any Pods work** but having them will make all subsequent iterations of Pods simpler. This is mainly because we can group top-level namespaces for a single organization onto a Pod. Within an organization all interactions work as normal but we eliminate any cross-organizational interactions except in well defined cases (e.g. forking).
+as a way to group top-level namespaces together. Support for organizations **does not require any Cells work** but having them will make all subsequent iterations of Cells simpler. This is mainly because we can group top-level namespaces for a single organization onto a Cell. Within an organization all interactions work as normal but we eliminate any cross-organizational interactions except in well defined cases (e.g. forking).
 
-This means that we don't have a large number of cross-pod interactions.
+This means that we don't have a large number of cross-cell interactions.
 
-Introducing organizations allows GitLab to move towards a multi-tenant system that is similar to Discord's with a single user account but many different "servers" - our organizations - that allow users to switch context. This model harmonizes the UX across self-managed and our SaaS Platforms and is a good fit for Pods.
+Introducing organizations allows GitLab to move towards a multi-tenant system that is similar to Discord's with a single user account but many different "servers" - our organizations - that allow users to switch context. This model harmonizes the UX across self-managed and our SaaS Platforms and is a good fit for Cells.
 
 Organizations solve the following problems:
 
@@ -254,7 +256,7 @@ Organizations solve the following problems:
 
 #### Why would customers opt-in to Organizations?
 
-By introducing organizations and Pods we can improve the reliability, performance and availability of our SaaS Platforms.
+By introducing organizations and Cells we can improve the reliability, performance and availability of our SaaS Platforms.
 
 The first iteration of organizations would also have some benefits by providing more isolation. A simple example would be that `@` mentions could be scoped to an organization.
 
@@ -274,37 +276,37 @@ Existing customers could also opt-in to migrate their existing top-level paid na
 
 Migrating to Organizations would be optional. We could even recruit a few beta testers early on to see if this works for them. GitLab itself could dogfood organizations and we'd surface a lot of issues restricting interactions with other namespaces.
 
-## Iteration 1 - Introduce Pod US 0
+## Iteration 1 - Introduce Cell US 0
 
-### GitLab.com as Pod US0
+### GitLab.com as Cell US0
 
-GitLab.com will be treated as the first pod `Pod US 0`. It will be unique and much larger compared to newly created pods. All existing top-level namespaces and organizations will remain on `Pod US 0` in the first iteration.
+GitLab.com will be treated as the first cell `Cell US 0`. It will be unique and much larger compared to newly created cells. All existing top-level namespaces and organizations will remain on `Cell US 0` in the first iteration.
 
 ### Users are globally available
 
-Users are globally available and the same for all pods. This means that user data needs to be handled separately, for example via decomposition, see [!95941](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/95941).
+Users are globally available and the same for all cells. This means that user data needs to be handled separately, for example via decomposition, see [!95941](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/95941).
 
-### Pod groundwork
+### Cell groundwork
 
-In this iteration, we'll lay all the groundwork to support a second Pod for new organizations. This will be transparent to customers.
+In this iteration, we'll lay all the groundwork to support a second Cell for new organizations. This will be transparent to customers.
 
-## Iteration 2 - Introduce Pod US 1
+## Iteration 2 - Introduce Cell US 1
 
-### Add new organizations to Pod US 1
+### Add new organizations to Cell US 1
 
-After we are ready to support a second Pod, newly created organizations are located by default on `Pod US 1`. The user experience for organizations is already well established.
+After we are ready to support a second Cell, newly created organizations are located by default on `Cell US 1`. The user experience for organizations is already well established.
 
-### Migrate existing organizations from Pod US 0 to Pod US 1
+### Migrate existing organizations from Cell US 0 to Cell US 1
 
-We know that we'll have to move organizations from `Pod US 0` to other pods to reduce its size and ultimately retire the existing GitLab.com architecture.
+We know that we'll have to move organizations from `Cell US 0` to other cells to reduce its size and ultimately retire the existing GitLab.com architecture.
 
-By introducing organizations early, we should be able to draw strong "boundaries" across organizations and support migrating existing organizations to a new Pod.
+By introducing organizations early, we should be able to draw strong "boundaries" across organizations and support migrating existing organizations to a new Cell.
 
 This is likely going to be GitLab itself - if we can dogfood this, we are likely going to be successful with other organizations as well.
 
 ## Iteration 3 - Introduce Regions
 
-We can now leverage the Pods architecture to introduce Regions.
+We can now leverage the Cells architecture to introduce Regions.
 
 ## Iteration 4 - Introduce cross-organizational interactions as needed
 
@@ -314,43 +316,43 @@ Based on user research, we may want to change certain features to work across or
 
 ## Technical Proposals
 
-The Pods architecture do have long lasting implications to data processing, location, scalability and the GitLab architecture.
+The Cells architecture do have long lasting implications to data processing, location, scalability and the GitLab architecture.
 This section links all different technical proposals that are being evaluated.
 
-- [Stateless Router That Uses a Cache to Pick Pod and Is Redirected When Wrong Pod Is Reached](proposal-stateless-router-with-buffering-requests.md)
+- [Stateless Router That Uses a Cache to Pick Cell and Is Redirected When Wrong Cell Is Reached](proposal-stateless-router-with-buffering-requests.md)
 
-- [Stateless Router That Uses a Cache to Pick Pod and pre-flight `/api/v4/pods/learn`](proposal-stateless-router-with-routes-learning.md)
+- [Stateless Router That Uses a Cache to Pick Cell and pre-flight `/api/v4/cells/learn`](proposal-stateless-router-with-routes-learning.md)
 
 ## Impacted features
 
-The Pods architecture will impact many features requiring some of them to be rewritten, or changed significantly.
+The Cells architecture will impact many features requiring some of them to be rewritten, or changed significantly.
 This is the list of known affected features with the proposed solutions.
 
-- [Pods: Git Access](pods-feature-git-access.md)
-- [Pods: Data Migration](pods-feature-data-migration.md)
-- [Pods: Database Sequences](pods-feature-database-sequences.md)
-- [Pods: GraphQL](pods-feature-graphql.md)
-- [Pods: Organizations](pods-feature-organizations.md)
-- [Pods: Router Endpoints Classification](pods-feature-router-endpoints-classification.md)
-- [Pods: Schema changes (Postgres and Elasticsearch migrations)](pods-feature-schema-changes.md)
-- [Pods: Backups](pods-feature-backups.md)
-- [Pods: Global Search](pods-feature-global-search.md)
-- [Pods: CI Runners](pods-feature-ci-runners.md)
-- [Pods: Admin Area](pods-feature-admin-area.md)
-- [Pods: Secrets](pods-feature-secrets.md)
-- [Pods: Container Registry](pods-feature-container-registry.md)
-- [Pods: Contributions: Forks](pods-feature-contributions-forks.md)
-- [Pods: Personal Namespaces](pods-feature-personal-namespaces.md)
-- [Pods: Dashboard: Projects, Todos, Issues, Merge Requests, Activity, ...](pods-feature-dashboard.md)
-- [Pods: Snippets](pods-feature-snippets.md)
-- [Pods: Uploads](pods-feature-uploads.md)
-- [Pods: GitLab Pages](pods-feature-gitlab-pages.md)
-- [Pods: Agent for Kubernetes](pods-feature-agent-for-kubernetes.md)
+- [Cells: Git Access](pods-feature-git-access.md)
+- [Cells: Data Migration](pods-feature-data-migration.md)
+- [Cells: Database Sequences](pods-feature-database-sequences.md)
+- [Cells: GraphQL](pods-feature-graphql.md)
+- [Cells: Organizations](pods-feature-organizations.md)
+- [Cells: Router Endpoints Classification](pods-feature-router-endpoints-classification.md)
+- [Cells: Schema changes (Postgres and Elasticsearch migrations)](pods-feature-schema-changes.md)
+- [Cells: Backups](pods-feature-backups.md)
+- [Cells: Global Search](pods-feature-global-search.md)
+- [Cells: CI Runners](pods-feature-ci-runners.md)
+- [Cells: Admin Area](pods-feature-admin-area.md)
+- [Cells: Secrets](pods-feature-secrets.md)
+- [Cells: Container Registry](pods-feature-container-registry.md)
+- [Cells: Contributions: Forks](pods-feature-contributions-forks.md)
+- [Cells: Personal Namespaces](pods-feature-personal-namespaces.md)
+- [Cells: Dashboard: Projects, Todos, Issues, Merge Requests, Activity, ...](pods-feature-dashboard.md)
+- [Cells: Snippets](pods-feature-snippets.md)
+- [Cells: Uploads](pods-feature-uploads.md)
+- [Cells: GitLab Pages](pods-feature-gitlab-pages.md)
+- [Cells: Agent for Kubernetes](pods-feature-agent-for-kubernetes.md)
 
 ## 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)
+- [Cells 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)
diff --git a/locale/gitlab.pot b/locale/gitlab.pot
index 6ca1caa6115..d2f30ef520b 100644
--- a/locale/gitlab.pot
+++ b/locale/gitlab.pot
@@ -27013,6 +27013,15 @@ msgstr ""
 msgid "MergeRequests|An error occurred while saving the draft comment."
 msgstr ""
 
+msgid "MergeRequests|Can't perform this action automatically. It may have already been done, or a more recent commit may have updated some of this content. Please perform this action locally."
+msgstr ""
+
+msgid "MergeRequests|Commit cherry-pick failed"
+msgstr ""
+
+msgid "MergeRequests|Commit revert failed"
+msgstr ""
+
 msgid "MergeRequests|Create issue to resolve thread"
 msgstr ""
 
@@ -27022,6 +27031,12 @@ msgstr ""
 msgid "MergeRequests|Mark as draft"
 msgstr ""
 
+msgid "MergeRequests|Merge request cherry-pick failed"
+msgstr ""
+
+msgid "MergeRequests|Merge request revert failed"
+msgstr ""
+
 msgid "MergeRequests|Reference copied"
 msgstr ""
 
diff --git a/spec/controllers/projects/commit_controller_spec.rb b/spec/controllers/projects/commit_controller_spec.rb
index 1a925f2ea4d..36206a88786 100644
--- a/spec/controllers/projects/commit_controller_spec.rb
+++ b/spec/controllers/projects/commit_controller_spec.rb
@@ -2,7 +2,7 @@
 
 require 'spec_helper'
 
-RSpec.describe Projects::CommitController do
+RSpec.describe Projects::CommitController, feature_category: :source_code_management do
   include ProjectForksHelper
 
   let_it_be(:project)  { create(:project, :repository) }
@@ -254,7 +254,45 @@ RSpec.describe Projects::CommitController do
         post :revert, params: { namespace_id: project.namespace, project_id: project, start_branch: 'master', id: commit.id }
 
         expect(response).to redirect_to project_commit_path(project, commit.id)
-        expect(flash[:alert]).to match('Sorry, we cannot revert this commit automatically.')
+        expect(flash[:alert]).to match('Commit revert failed:')
+      end
+    end
+
+    context 'in the context of a merge_request' do
+      let(:merge_request) { create(:merge_request, :merged, source_project: project) }
+      let(:repository) { project.repository }
+
+      before do
+        merge_commit_id = repository.merge(user,
+          merge_request.diff_head_sha,
+          merge_request,
+          'Test message')
+
+        repository.commit(merge_commit_id)
+        merge_request.update!(merge_commit_sha: merge_commit_id)
+      end
+
+      context 'when the revert was successful' do
+        it 'redirects to the merge request page' do
+          post :revert, params: { namespace_id: project.namespace, project_id: project, start_branch: 'master', id: merge_request.merge_commit_sha }
+
+          expect(response).to redirect_to project_merge_request_path(project, merge_request)
+          expect(flash[:notice]).to eq('The merge request has been successfully reverted.')
+        end
+      end
+
+      context 'when the revert failed' do
+        before do
+          post :revert, params: { namespace_id: project.namespace, project_id: project, start_branch: 'master', id: merge_request.merge_commit_sha }
+        end
+
+        it 'redirects to the merge request page' do
+          # Reverting a merge request that has been already reverted.
+          post :revert, params: { namespace_id: project.namespace, project_id: project, start_branch: 'master', id: merge_request.merge_commit_sha }
+
+          expect(response).to redirect_to project_merge_request_path(project, merge_request)
+          expect(flash[:alert]).to match('Merge request revert failed:')
+        end
       end
     end
   end
@@ -297,7 +335,44 @@ RSpec.describe Projects::CommitController do
         post :cherry_pick, params: { namespace_id: project.namespace, project_id: project, start_branch: 'master', id: master_pickable_commit.id }
 
         expect(response).to redirect_to project_commit_path(project, master_pickable_commit.id)
-        expect(flash[:alert]).to match('Sorry, we cannot cherry-pick this commit automatically.')
+        expect(flash[:alert]).to match('Commit cherry-pick failed:')
+      end
+    end
+
+    context 'in the context of a merge_request' do
+      let(:merge_request) { create(:merge_request, :merged, source_project: project) }
+      let(:repository) { project.repository }
+
+      before do
+        merge_commit_id = repository.merge(user,
+          merge_request.diff_head_sha,
+          merge_request,
+          'Test message')
+        repository.commit(merge_commit_id)
+        merge_request.update!(merge_commit_sha: merge_commit_id)
+      end
+
+      context 'when the cherry_pick was successful' do
+        it 'redirects to the merge request page' do
+          post :cherry_pick, params: { namespace_id: project.namespace, project_id: project, start_branch: 'merge-test', id: merge_request.merge_commit_sha }
+
+          expect(response).to redirect_to project_merge_request_path(project, merge_request)
+          expect(flash[:notice]).to eq('The merge request has been successfully cherry-picked into merge-test.')
+        end
+      end
+
+      context 'when the cherry_pick failed' do
+        before do
+          post :cherry_pick, params: { namespace_id: project.namespace, project_id: project, start_branch: 'merge-test', id: merge_request.merge_commit_sha }
+        end
+
+        it 'redirects to the merge request page' do
+          # Reverting a merge request that has been already cherry-picked.
+          post :cherry_pick, params: { namespace_id: project.namespace, project_id: project, start_branch: 'merge-test', id: merge_request.merge_commit_sha }
+
+          expect(response).to redirect_to project_merge_request_path(project, merge_request)
+          expect(flash[:alert]).to match('Merge request cherry-pick failed:')
+        end
       end
     end
 
diff --git a/spec/features/merge_request/user_reverts_merge_request_spec.rb b/spec/features/merge_request/user_reverts_merge_request_spec.rb
index 43ce473b407..e09a4569caf 100644
--- a/spec/features/merge_request/user_reverts_merge_request_spec.rb
+++ b/spec/features/merge_request/user_reverts_merge_request_spec.rb
@@ -34,7 +34,7 @@ RSpec.describe 'User reverts a merge request', :js, feature_category: :code_revi
 
     revert_commit
 
-    expect(page).to have_content('Sorry, we cannot revert this merge request automatically.')
+    expect(page).to have_content('Merge request revert failed:')
   end
 
   it 'reverts a merge request in a new merge request', :sidekiq_might_not_need_inline do
diff --git a/spec/features/projects/commit/cherry_pick_spec.rb b/spec/features/projects/commit/cherry_pick_spec.rb
index 93ce851521f..b608fc953f3 100644
--- a/spec/features/projects/commit/cherry_pick_spec.rb
+++ b/spec/features/projects/commit/cherry_pick_spec.rb
@@ -56,7 +56,7 @@ RSpec.describe 'Cherry-pick Commits', :js, feature_category: :source_code_manage
 
         cherry_pick_commit
 
-        expect(page).to have_content('Sorry, we cannot cherry-pick this commit automatically.')
+        expect(page).to have_content('Commit cherry-pick failed:')
       end
     end
 
diff --git a/spec/features/projects/commit/user_reverts_commit_spec.rb b/spec/features/projects/commit/user_reverts_commit_spec.rb
index 8c7b8e6ba32..4d2abf55675 100644
--- a/spec/features/projects/commit/user_reverts_commit_spec.rb
+++ b/spec/features/projects/commit/user_reverts_commit_spec.rb
@@ -47,7 +47,7 @@ RSpec.describe 'User reverts a commit', :js, feature_category: :source_code_mana
 
         revert_commit
 
-        expect(page).to have_content('Sorry, we cannot revert this commit automatically.')
+        expect(page).to have_content('Commit revert failed:')
       end
     end
 
diff --git a/spec/workers/new_merge_request_worker_spec.rb b/spec/workers/new_merge_request_worker_spec.rb
index a8e1c3f4bf1..58f6792f9a0 100644
--- a/spec/workers/new_merge_request_worker_spec.rb
+++ b/spec/workers/new_merge_request_worker_spec.rb
@@ -107,18 +107,6 @@ RSpec.describe NewMergeRequestWorker, feature_category: :code_review_workflow do
               stub_feature_flags(add_prepared_state_to_mr: true)
             end
 
-            context 'when the merge request is prepared' do
-              before do
-                merge_request.update!(prepared_at: Time.current)
-              end
-
-              it 'does not call the create service' do
-                expect(MergeRequests::AfterCreateService).not_to receive(:new)
-
-                worker.perform(merge_request.id, user.id)
-              end
-            end
-
             context 'when the merge request is not prepared' do
               it 'calls the create service' do
                 expect_next_instance_of(MergeRequests::AfterCreateService, project: merge_request.target_project, current_user: user) do |service|