By the experiment in #29, I seem our hypothesis is true.

However, we need configure the concurrency group to use that optimization because it use github.ref.
https://github.com/tetsuharuohzeki/fastly-compute-at-edge-template/blob/72c7584d22d224cab55778d36dd2c545daa6e923/.github/workflows/ci.yaml#L9

Our current design caps the workflow concurrency at the top level workflow. So the concurrency group will not conflict.
However, if we remove the top level concurrency group, then the child level concurrency group will be used.

Our current design caps the workflow concurrency at the top level workflow. So the concurrency group will not conflict. However, if we remove the top level concurrency group, then the child level concurrency group will be used.

I experiment this design at #31 but it cannot resolve this perf issue.

By this design, deploy job is queued after all dependencies are completed. This mean that the lock by the concurrency group by delopy job is registered on that all dependencies are completed.

So if predecessor delays to complete their dependencies, successor will begin to run delopy job ahead of the predecessor. This cannot achieve our intention.