Load the run pipeline button independent of loading the rest of the pipeline data

added Category:Continuous Integration backend devopsverify frontend grouppipeline execution maintenanceworkflow needs weight sectionops typemaintenance workflowplanning breakdown labels

added to epic &5890

Hi @jheimbuck_gl - since #341462 (closed) was originally intended for %15.3 according to #359914 (closed) but we ended up creating this issue for clarity reasons, WDYT about attaching this into %15.3 to mirror the timing that was intended before?

@marknuzzo I left a comment about scheduling on the epic.

mentioned in issue #359914 (closed)

mentioned in epic &5890

changed milestone to %Backlog

changed milestone to %15.3

The related component can be found here app/assets/javascripts/commit/pipelines/pipelines_table.vue

Currently we render the table and the button together based on https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/commit/pipelines/pipelines_table.vue#L79

We have two Run pipeline buttons here. One for mobile and one for desktop. Right now the desktop button is actually rendered in the table using a slot. We would have to refactor the component to not use a slot and abstract the buttons.

Giving this a weight of 2 possibly could end up being a 3.

Async Update

After working on this the past few days, I don't think this is doable at the moment. I think if we want performance improvements here we should focus on lazy loading manual builds.

We show our loading state when we fetch the pipelines, we won't be able to display the Run pipeline button until we have successfully fetched pipelines (to know if we can even display it).

We could however always display the run pipeline button and throw and error even if MR pipelines aren't configured, but this could be bad UX. But I'm not sure it's worth it

I think we should move this back into planning breakdown. Apologies for not catching this sooner, I didn't find any of this out until I started actually working on it. If we do proceed with a UX change here, we would need a design for this. Or we could close this out and focus on performance improvements like lazy loading manual builds.

cc: @jheimbuck_gl @v_mishra

We could however always display the run pipeline button and throw and error even if MR pipelines aren't configured, but this could be bad UX. But I'm not sure it's worth it

Thanks for eventually catching the problem and setting the course right @pburdette You're right, we shouldn't show the button if the configuration doesn't exist. I missed the discussion that resulted into this issue: #341462 (comment 688272868)

I agree that the most common action on the page is to hit the Run pipeline button and that communicates the importance of that action. If we misguide users with that action, by surfacing it when the config doesn't exist, that would go against user's expectation.