Stages run in wrong order


I have a simple CI config:

  image: ...

  - test
  - publish

  only: [merge_requests]
  stage: test
    - ...

  stage: publish
    - ...

Note that I only want to run the test job for merge_requests.

Whenever a pipeline is triggered, the publish job is run, although it should be only started after all jobs of the test stage are run. Is this a bug?

BTW, I am using GitLab Community Edition 13.3.6


You have the condition “only: merge_requests” So normally, you’d expect only the publish stage to run, unless the pipeline is ran on a merge request. So on a commit to a branch for example, you’d expect the publish stage but not the test stage



But first and foremost, the publish stage should only ever run when the previous stage is done. (regardless whether there are jobs in the previous stage that have only/except clauses)

No, only if you add a dependency on another step (not sure how that is configured though). Stages are not dependent on other stages to be executed if that is not specified

What do you mean?


The specification of stages allows for having flexible multi stage pipelines. The ordering of elements in stages defines the ordering of jobs’ execution:

  1. Jobs of the same stage are run in parallel.
  2. Jobs of the next stage are run after the jobs from the previous stage complete successfully.

This clearly does not work in the merge request case, as it fires the publish job of the publish stage first, while the test job of the test stage is queued.

I meant that it was logic for the case when it wasn’t a merge request. If the publish job goes first in a pipeline triggered by a MR and the test job is executed second, then it does seems that there’s something wrong, but I wouldn’t know what

@avdv I agree @bartj is correct.

To only run publish job if not merge_request source:

  except: [merge_requests]
  stage: publish
    - ...

That’s not what I want. I want to have the publish job run always (for merge requests and for pushes to branches / tags).

I take it that this is really a bug in Gitlab, I’ll file an issue…