Ezekiel Kigbo (414b0873) at 19 Mar 00:36

note: custom_dashboards_foundation seems like a better fit since analytics dashboards is broader than just value stream management

Good question, this will be added later once we implement the graphql queries to fetch the list of dashboards, for now it will always be empty #589182

Ezekiel Kigbo (a17fb836) at 19 Mar 00:23

Hi @lvanc would you be free to give this a quick UX review? I took a guess at a "empty state" when there are no dashboards available to list.

For now, the dashboard list is empty, but when #589182 is implemented we should be able to fetch the dashboards that are available in the postgres database (there will likely be a migration added to seed some dashboards)

Thanks @smaglangit, just a couple of tiny nitpicks.

I am a bit curious about the why for this change?

We already had 2 separate components, but the new shared component just adds them together with the only change seeming to be to centralize the button actions, but I wonder if we could have just created separate redirectConfig, leaveMessage and deleteMessage functions that we call from the existing components.

This is incomplete and untested, but hopefully illustrative of what I mean

diff --git a/app/assets/javascripts/vue_shared/components/projects_list/project_list_item_actions.vue b/app/assets/javascripts/vue_shared/components/projects_list/project_list_item_actions.vue
index 7a4a8c6f0b7b..159f7782cc13 100644
--- a/app/assets/javascripts/vue_shared/components/projects_list/project_list_item_actions.vue
+++ b/app/assets/javascripts/vue_shared/components/projects_list/project_list_item_actions.vue
@@ -30,6 +30,43 @@ import {
 } from './utils';
 import ProjectsListItemLeaveModal from './projects_list_item_leave_modal.vue';
 
+// TODO: move these methods to a `utils` folder
+const redirectConfig = ({ path, id, deleteMessage, leaveMessage }) => {
+  return {
+    [ACTION_DELETE_IMMEDIATELY]: {
+      path,
+      alerts: [
+        {
+          id,
+          message: deleteMessage,
+          variant: 'info',
+        },
+      ],
+    },
+    [ACTION_LEAVE]: {
+      path,
+      alerts: [
+        {
+          id,
+          message: leaveMessage,
+          variant: 'info',
+        },
+      ],
+    },
+  };
+};
+
+const handleHeadActionRedirect = ({ action, resourceFullPath }) => {
+  const { alerts, path = resourceFullPath } = this.redirectConfig[action] || {};
+  const url = new URL(path, window.location.origin);
+
+  if (alerts) {
+    visitUrlWithAlerts(url.href, alerts);
+  } else {
+    visitUrl(url.href);
+  }
+};
+
 export default {
   name: 'ProjectListItemActions',
   components: {
@@ -209,7 +246,11 @@ export default {
 
         this.$emit(
           'action',
-          this.project.markedForDeletion ? ACTION_DELETE_IMMEDIATELY : ACTION_DELETE,
+
+          handleHeadActionRedirect({
+            action: this.project.markedForDeletion ? ACTION_DELETE_IMMEDIATELY : ACTION_DELETE,
+            resourceFullPath: '',
+          }),
         );
         renderDeleteSuccessToast(this.project);
       } catch (error) {
@@ -228,7 +269,10 @@ export default {
       this.isLeaveModalVisible = true;
     },
     onLeaveSuccess() {
-      this.$emit('action', ACTION_LEAVE);
+      this.$emit(
+        'action',
+        handleHeadActionRedirect({ action: ACTION_LEAVE, resourceFullPath: '' }),
+      );
     },
   },
 };

Same comment as above re: casing

nitpick: any reason for the mixed case in this method? Might be better to keep it consistent.

        return sprintf(__('You left the "%{groupName}" group.'), {
          groupName: this.resource.fullName,

not-blocking: @smaglangit I do wonder if it would make sense to be a bit more specific with the name of the component and file? Even though the import path contains groups_projects, I wonder if the name HeaderActionsDropdown is a little too generic.

Perhaps NamespaceActionsDropdown? - not blocking though!

Ezekiel Kigbo (31b474e3) at 18 Mar 07:17

Ezekiel Kigbo (965dccd3) at 18 Mar 06:51

... and 3 more commits

Ezekiel Kigbo (55ef70c8) at 18 Mar 03:27

... and 324 more commits

Ezekiel Kigbo (565a60ab) at 18 Mar 02:32

... and 1 more commit

Ezekiel Kigbo (39ddc394) at 18 Mar 02:32

What does this MR do and why?

Subscribe to the ciStageStatusUpdated GraphQL subscription in PipelineStageDropdown so stage icons in the MR pipeline mini graph update in real-time when their status changes (e.g., pending → running → success).

Background

This is part of the MR Pipelines migration to GraphQL epic, which aims to migrate the MR Pipelines tab to use GraphQL. As part of this migration, we're leveraging GraphQL subscriptions to make the pipeline mini graph real-time, providing an improved user experience. Previously, we implemented real-time updates at the pipeline level. This MR extends that work to individual stage statuses.

Solution

• Add new ci_stage_status_updated.subscription.graphql with @feature_category
• Subscribe only to "alive" stages (running, pending, etc.) to minimize WebSocket overhead
• Automatically unsubscribe when a stage reaches a terminal status
• Add double-subscription guard to prevent leaked subscriptions
• Add stage watcher to re-subscribe when stage prop changes (component reuse)
• Inline the MR pipelines GraphQL query (decoupled from shared PipelineDetails fragment) to add detailedStatus.name on stages without increasing complexity for other consumers
• Inject parent mergeRequest data into each pipeline object (replaces the per-pipeline mergeRequest field that was on the shared fragment)

The MR pipelines GraphQL page is behind the mr_pipelines_graphql feature flag.

This is Part 1 of 4 in the real-time MR pipeline mini graph series.

Visual Changes

How to set up and validate locally

1. Enable the feature flags in Rails console:

   Feature.enable(:mr_pipelines_graphql)
   Feature.enable(:pipeline_mini_graph_subscription)

2. Open a merge request and trigger a new pipeline
3. Open browser dev tools → Network → WS → find cable connection
4. Verify ciStageStatusUpdated messages appear when stages change status
5. Observe that stage icons update immediately as jobs progress
6. Verify that completed stages (success/failed) do not have active subscriptions

References

• Issue: #591338
• Parent epic: &14144
• Backend MR: !224756 (merged)
• Query complexity: #584293 (inlining the query avoids increasing complexity of the shared PipelineDetails fragment)
• Part 2 (parallel): !227494
• Part 3: !227496
• Part 4: !227497

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Ezekiel Kigbo (016be3af) at 18 Mar 02:29

... and 2 more commits

Hi @rsarangadharan are you able to help review this community contribution?

Thanks for updating, this looks great. I'll set MWPS.

What does this MR do and why?

Subscribe to the ciStageStatusUpdated GraphQL subscription in PipelineStageDropdown so stage icons in the MR pipeline mini graph update in real-time when their status changes (e.g., pending → running → success).

Background

This is part of the MR Pipelines migration to GraphQL epic, which aims to migrate the MR Pipelines tab to use GraphQL. As part of this migration, we're leveraging GraphQL subscriptions to make the pipeline mini graph real-time, providing an improved user experience. Previously, we implemented real-time updates at the pipeline level. This MR extends that work to individual stage statuses.

Solution

• Add new ci_stage_status_updated.subscription.graphql with @feature_category
• Subscribe only to "alive" stages (running, pending, etc.) to minimize WebSocket overhead
• Automatically unsubscribe when a stage reaches a terminal status
• Add double-subscription guard to prevent leaked subscriptions
• Add stage watcher to re-subscribe when stage prop changes (component reuse)
• Inline the MR pipelines GraphQL query (decoupled from shared PipelineDetails fragment) to add detailedStatus.name on stages without increasing complexity for other consumers
• Inject parent mergeRequest data into each pipeline object (replaces the per-pipeline mergeRequest field that was on the shared fragment)

The MR pipelines GraphQL page is behind the mr_pipelines_graphql feature flag.

This is Part 1 of 4 in the real-time MR pipeline mini graph series.

Visual Changes

How to set up and validate locally

1. Enable the feature flags in Rails console:

   Feature.enable(:mr_pipelines_graphql)
   Feature.enable(:pipeline_mini_graph_subscription)

2. Open a merge request and trigger a new pipeline
3. Open browser dev tools → Network → WS → find cable connection
4. Verify ciStageStatusUpdated messages appear when stages change status
5. Observe that stage icons update immediately as jobs progress
6. Verify that completed stages (success/failed) do not have active subscriptions

References

• Issue: #591338
• Parent epic: &14144
• Backend MR: !224756 (merged)
• Query complexity: #584293 (inlining the query avoids increasing complexity of the shared PipelineDetails fragment)
• Part 2 (parallel): !227494
• Part 3: !227496
• Part 4: !227497

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.