Regression in merge request pipeline creation

A Regression!

There appears to be a regression in the recent improvements made to the merge request pipeline experience.

The Recent Improvements:

1. Fix Merge button mergeability when pipeline cre... (#479811 - closed)
2. Async MR Pipeline creation - iteration 1 (#476627 - closed)

After those improvements, the merge request pipeline creation looked like this:

Screen_Recording_2024-09-23_at_14.05.23.mov

Note that the Merge is blocked immediately after "Run pipeline" is clicked.

The Regression

Now that experience looks like this:

Screen Recording 2025-02-05 at 17.06.57.mov

Note that the Merge button stays enabled until the pipeline creations finishes. This video is from my GDK, and I've observed this behavior on gitlab.com as well.

What happened?

I'm not sure yet It might be related to the changes I made in Backend: Implement PipelineCreations::Request i... (#488392 - closed), but I haven't been able to confirm that yet

added grouppipeline authoring typebug workflowplanning breakdown labels

assigned to @avielle

added devopsverify sectionci labels

changed the description

added gitlab-org#16689 as parent epic

removed parent epic gitlab-org#16689

@bsandlin @lauraXD it looks like the improvements we made last quarter have been undone I wrote up a summary in the description, but I'm not sure what happened yet. It might be related to the changes I made in Backend: Implement PipelineCreations::Request i... (#488392 - closed) (I'll investigate this). Do either of you know of any other changes that could have caused this?

cc @sunjungp since these were user experience improvements

added severity2 label

assigned to @lauraXD and unassigned @avielle

assigned to @avielle

mentioned in issue gitlab-org/ci-cd/pipeline-authoring#188

added priority2 label

mentioned in issue gitlab-org/quality/triage-reports#22302 (closed)

@bsandlin @lauraXD I did some digging and might have found the culprit: Change the hurestic used when determining if ci... (!180183 - merged). It was merged a week ago, which is about the same time I began observing the regression

However, I reverted that change and there still seems to be something wrong. The GraphQL subscription isn't updating as expected, and I'm not sure why. Thankfully, the data store is updating properly since that'd be the biggest headache to fix if it was broke

When I have a chance I'll take a deeper look into the recent changes to the MR pipeline mergeability checks

@avielle

The GraphQL subscription isn't updating as expected, and I'm not sure why

As-in, the GraphQL subscription doesn't trigger when the pipeline creation is complete? or something else

@bsandlin it doesn't trigger when the pipeline creation begins. Nothing seems to have changed around the line of code that's supposed to trigger it, but it just…doesn't work now

@avielle I see that some changes were made recently to our Requests class: 82cf739d that touches this directly :/ this might be a good place to start.

@lauraXD that could definitely be related Something very weird is going on here, possibly due to those changes. The creation request gets created IN_PROGRESS as expected, then gets set to FAILED (but it doesn't fail!), and then eventually when the pipeline is created it's set to SUCCEEDED

If I remove this line, everything works as expected: https://gitlab.com/gitlab-org/gitlab/-/blob/9ce6537e839f08f42f2596d11ca7e1bae57c0d46/app/services/merge_requests/create_pipeline_service.rb#L82

I don't know yet why this began being a problem. That line itself is correct, but the method it's in is being called somewhere incorrectly

Another candidate for the cause: 8cb2bf85

Stacktrace (with StandardError I added for debugging) of the path leading to the erroneous marking of the creation as failed:

Branch with some debugging code (for when I pick this back up): master...fix-mr-pipelines-regression

@avielle I attempted to investigate but then I bricked my gdk trying to migrate to mise. I will check back in tomorrow

@bsandlin I bricked my GDK migrating to mise last week too GOOD LUCK

Is this why if I approve someone else's MR, and then set it to merge after pipeline, it gets blocked because it now says I the approver made a code change? This is making it impossible for me to manage MRs for the project I work on.

Specifically:

User opens MR other changes occur in mainline I approve and choose rebase

My approval is now invalidated because "I made a commit" to the MR.

Let me know if this should be tracked under a different issue.

unassigned @lauraXD

@lauraXD @bsandlin @sunjungp I'm now more confused than ever I spent a while investigating this issue and realized that a line related to the merge_pipelines feature being available was returning false for me. Apparently I'd lost the Ultimate license I used to have on my GDK. So I re-added it and…everything started working as expected

Screen_Recording_2025-02-13_at_17.25.52

I need to step away from this investigation for a bit. When I return I'll try to figure out these items:

• Why doesn't this work properly when the merge_pipelines feature is unavailable?
• merge_pipelines is available for gitlab-org/gitlab, so why have I seen the regression in that project? Do I still see it?

@avielle I started investigating as well today but this works for me now too

@bsandlin oh boy Well…I'm going to pause my active investigation on this issue and observe the MRs I maintain in gitlab-org/gitlab. If I don't see the regression occur over a few week's time I'll close this issue

@bsandlin @lauraXD @sunjungp thank you all for your help looking into this

changed milestone to %17.11

mentioned in issue gitlab-org/quality/triage-reports#22380 (closed)

mentioned in issue gitlab-org/quality/triage-reports#22486

mentioned in issue gitlab-org/quality/triage-reports#22681