unfair ordering of jobs in build queue

When a commit is pushed, its build jobs (or first stage jobs) are put at the end of the queue. Its other jobs are not put in the queue, since they might not need to run if a previous stage job fails. So far so good.

However, when a stage succeeds, the jobs of the next stage are put at the end of the queue again. This is fine if no other pipeline has started in the meantime. However, if there was a new pipeline, it "jumps the queue", and we need to wait until its build finishes, before we could start the second phase of the first pipeline.

This can lead to a situation when someone pushes a branch, but its testing never finishes, because new commits are pushed repeatedly and there's always at least build job in the queue.

There are currently 15 concurrent pipelines running in our system because of this way of scheduling, most of them waiting at the test or clean-up stage, but they cannot finish until every new build job finishes. (Hopefully no one pushes a new commit.)

It is true that in the end the pipelines will finish in the same order as they started. But the jobs of a new pipeline should not precede the jobs of an earlier pipeline, otherwise the running pipelines can pile up very easily.

In my opinion, when a stage finishes, the jobs of the next stage should be put in the queue at the same position where the last job of the stage was, and not at the end.