Multiple Gitlab pipelines per commit

[bobvandevijver]

So, I'm basically experiencing what is described in #5743: I get two pipelines for every commit in Gitlab when using the stabilityDays functionality.

This actually already caused an MR to be merged while the pipeline wasn't completed yet. Note that this happened after an automatic rebase to make the change directly mergable.

As, as you can see, the renovate pipeline was considered to be enough.

This means that even when my own pipeline fails, renovate will still be able to merge due to the simple stability check being green.

When looking at the API documentation of Gitlab and testing it myself on a test branch with MR and pipeline, it seems to work as you would expect: the status is added to the existing pipeline for the commit sha.

That leads me to think that this is just a simple race condition, and that just waiting a bit for the pipeline creation would already solve this. Any opinions?

[bobvandevijver]

A possible solution would be to not use the commit status at all: the check is already done in the renovate runner, so if it is converted into a checkbox in the MR description (which can be positioned under the "automerge" imo) it would be very nice.

That way, a developer can easily choose to skip the stabilityDays check by checking the box manually, and otherwise we wait for the next renovate run that checks the box when the stability condition is met (so renovate can never untick the box after having created it).

The state of the checkbox can then be used to determine whether or not the MR is automerge ready.

I do believe this might be an excellent feature for every platform.

[bobvandevijver]

Sure, but currently that doesn't work as intended in Gitlab as it doesn't have the real status checks as Github does have. Most certainly not when you require the pipeline to complete successfully before merge.

That's why I would expect to see some status message in the description (or maybe as comment) from the bot about the stability days: your own pipeline is in that case the only one that runs and can be used for the Gitlab requirement.

That also means that renovate shouldn't try automerging until the stability days has been met (it does check that during its run right?). It can directly update the description or post a comment stating that the stability days have been met. That way, we won't even need the checkbox.

And this can well be Gitlab only behaviour imho.

[viceice]

maybe a small delay like in bitbucket-server would solve this issue until gitlab will solve this?

renovate/lib/platform/bitbucket-server/index.ts

Lines 372 to 377 in 3e2d9ca

	export async function refreshPr(number: number): Promise<void> {
	// wait for pr change propagation
	await delay(1000);
	// refresh cache
	await getPr(number, true);
	}

[bobvandevijver]

I believe that might indeed be a solution to solve the double pipeline creation

[bobvandevijver]

The screenshot below illustrates the race condition quite well I guess: this particular MR has been rebased twice, but only once the status check created a separate pipeline.

I will create a small PR that adds a small delay before the Gitlab API is called to add the branch status.

[bobvandevijver]

With the change from #8771 the placement of the stability days check is much, much more predicable 😃
It is not 100%, but that is probably due to the fact that the onboarding process is still running, so a lot of branches, prs and pipelines are created at the same time.