Does `queue/until_front_of_line` guarantee a correct deployment order?

[gdubicki]

Hi!

Thank you for this project!

However, I have a doubt that prevents me from using queue/until_front_of_line for the use case that you describe in the docs:

Used to ensure that a only single job (deploy) is not run concurrently. By default will only queue if the same job from previous workflows is running on the same branch. This allows safe jobs like build/test to overlap, minimizing overall queue times

---

Imagine that you have a repo with a single workflow that runs 2 jobs sequentially:

1. test
2. deploy

The "test" job can take various amounts of time, let's say from 10 to 60 seconds.

The "deploy" job one has queue/until_front_of_line as the first step.

---

Now let's say we push 2 commits to the master branch of this repo, commit A first and then commit B, 10 seconds later.

This time the "test" job took 30 seconds for commit A but just 5 seconds for commit B.

---

My question is: which "deploy" job will run first, for commit A or commit B?

[tkoft]

It depends if you have block-workflow set.

If you look at the orb source, it "queues" by workflow creation time, not job start time. Ifblock-workflow is set true, your second deploy job will block until the first workflow is not running any jobs.

If block-workflow is false, as is the default, then deploy #2 will only block if deploy #1 is actively running. You only ensure that no deploys run at the same time--order is not guaranteed.