External jobs invoke a concurrent empty pipeline

We have a traditional pipeline with jobs using only: branches. We use tools like Snyk and Renovate and they inject an external job into the pipeline.

Sometimes this external job is not added to a pipeline, but it creates a brand new empty pipeline.
That can be very dangerous. The MR is showing as successful, while it’s linking a pipeline with only contains 1 external job. The real pipeline is failing. Renovate has automerge enabled, so it will merge the failing code into our main branch.

Is there a way to prevent this or work around it in Gitlab? Ideally, the external job is always added to the right pipeline and can never start a blank pipeline with only external jobs. I’ve seen this happen for both Snyk and Renovate external jobs.

You can see the issue clearly in these pictures:

Here the last pipeline only contains external jobs, so the MR seems ok, but actually contains failing code.

This is what I expect to get in all cases. In some cases, it has this right behavior:

Our jobs are pretty simple, built as follows:

  stage: 📦 Build
    - ...
  interruptible: true
    - branches

On snyk.io we have an integration enabled with our self-managed Gitlab, that takes care of adding the external jobs?

It could be a concurrency issue. The pipeline which only has external jobs was triggered at Apr 20, 2023 2:54pm GMT+0200 and the real pipeline was also triggered at this exact time.

I really need to find a way to avoid these external jobs from making a new pipeline, as this messes with the MR status and could lead to bad auto-merging. :pray:

Seems related to Race condition in commit status API creates multiple pipelines (#13134) · Issues · GitLab.org / GitLab · GitLab and GitLab: Two pipelines per MR · Issue #5743 · renovatebot/renovate · GitHub, but concluding that it’s a Gitlab bug and not really a Snyk/Renovate bug.