zlacker

In GitLab you can limit concurrency by using a resource group https://about.gitlab.com/blog/2020/01/21/introducing-resourc...

Does that address your need?

Edit with more context: We use CI for deploying to GitLab.com and use resource_group to prevent multiple jobs from running concurrently. What we lack is the ability to prevent multiple pipelines from running concurrently (resource_group is at the job level). It looks like concurrency for actions https://docs.github.com/en/actions/reference/workflow-syntax... can work on groups which is a bit nicer. There is some discussion about making this better for GitLab in https://gitlab.com/gitlab-org/gitlab/-/issues/217522

>>sytse+(OP)
While doing it at the job level is handy, doing it at the workflow or cross-job level is likely to become necessary as the complexity of the workflow scales. CircleCI has similar issues, syncing on one job can be done with a plugin, but cross-job sync never really works, and in our 10 step workflow where we have deploys queueing up in quick succession, we often find ordering issues.

GitHub Action's, Semaphore's, or even Jenkin's, concurrency primitives are pretty capable so I'd probably go with one of those.