We've done continuous delivery through various CI systems for many years. Originally Jenkins, then CircleCI, now GitHub Actions.
When we originally moved from Jenkins I was quite taken aback by CircleCI's lack of ability to do this – Jenkins has many primitives around queueing/locking/critical sections/resource allocation. There were other benefits over Jenkins that made it still a worthwhile transition, but it really took the steam out of it. We've hit so many problems over the years on CircleCI with deployments running over each other.
There is an "orb" that implements queueing, but it has its own race conditions that make it only a ~99% solution (and at many deploys a day that's unreliable), plus you have to pay for the queueing time because it's essentially a loop in a bash script.
SemaphoreCI has some nice primitives for this, you can define queues with their own parallelism separate to your workflows, and then depend on them from workflows, and everything synchronises according to that parallelism.
It's great to see GitHub Actions add something similar.
Am I missing a reason that this seems to have been so far down the priority list of products like CircleCI, GitHub Actions, and I believe, most other CI products?
When we originally moved from Jenkins I was quite taken aback by CircleCI's lack of ability to do this – Jenkins has many primitives around queueing/locking/critical sections/resource allocation. There were other benefits over Jenkins that made it still a worthwhile transition, but it really took the steam out of it. We've hit so many problems over the years on CircleCI with deployments running over each other.
There is an "orb" that implements queueing, but it has its own race conditions that make it only a ~99% solution (and at many deploys a day that's unreliable), plus you have to pay for the queueing time because it's essentially a loop in a bash script.
SemaphoreCI has some nice primitives for this, you can define queues with their own parallelism separate to your workflows, and then depend on them from workflows, and everything synchronises according to that parallelism.
It's great to see GitHub Actions add something similar.
Am I missing a reason that this seems to have been so far down the priority list of products like CircleCI, GitHub Actions, and I believe, most other CI products?