Don't create pipeline on creation of the merge request

Problem to solve

We are using merge request and branch pipelines, see: Types of pipelines | GitLab Docs
It is already configured that branch pipelines will not be created if there is an MR for the branch.

My usual workflow is to create a branch, add some commits and then, when I push it for the first time to the remote I will also then create a merge request for it.
This results in two pipelines for the same branch, once because I pushed the branch and the second one because the merge request was created.
See: Merge request pipelines | GitLab Docs

Is there a way to find out via any Predefined CI/CD variables reference | GitLab Docs whether this merge_request_event was due to the creation of the MR or just because it was updated? I basically don’t ever want to create a new pipeline just because the MR created. Only if I push a commit.

So code like this the following is not what I’m looking for as I generally want MR pipelines

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
      when: never

I usually see this handled by push pipelines being inhibited while there is a merge request:

```

workflow:
  rules:
  - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  - if: $CI_MERGE_REQUEST_IID
    when: never
    

May I ask, why do you then use MR pipelines at all?

You don’t have to configure MR pipelines, branch pipelines are enough and will be there even when you open a Merge Request.

I am not sure if there is a way to avoid the scenario you’re describing. GitLab will trigger a pipeline on push (regular branch pipeline) and in this case, additionally for an MR because that happened a tiny bit after the actual push. And you cannot create an MR before you actually push a branch, so…

Unless you’re executing more jobs on MR pipeline compared to branch pipeline… my advice would be just to use either one, not both.

I used to add –push-option ci.skip. That was disabling the ci for the branch, but not for the MR.