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
The specification of stages allows for having flexible multi stage pipelines. The ordering of elements in stages defines the ordering of jobs’ execution:
Jobs of the same stage are run in parallel.
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