I’d like to have a deploy pipeline with steps to deploy to multiple environments, ending in a production deploy. I’m intending for this pipeline to be triggered by a successful run of a build/test pipeline. It sounds like I can use concurrency groups to ensure that only a single deploy is happening at any one time.
My questions is do triggered pipelines inherit ordering from triggering builds? My concern is that if I have two merges, resulting in two build/test pipeline runs, the second may complete and trigger it’s deploy before the first. eg:
- build/test for first merge
- build/test for second merge
- deploy for second merge
- deploy for first merge - accidentally removes features added in second merge
I can’t find any explicit documentation on the behaviour here in the concurrency docs linked or the trigger step docs.
hi @uh-toby,
Welcome to the Buildkite Support Community! 
We have a blog that explains concurrency gates that you might find useful. You can read more about it here Concurrency Gates - Buildkite Blog. If you put your deploy steps in concurrency gates, this would ensure the order when they run.
Cheers!
Hi @lizette ,
Thanks for the link, useful reading! If I understand, since concurrency group labels are accessible by all pipelines in an organization the concurrency gate technique could be used across multiple pipelines.
I think that would mean that the triggering step would need to wait for the triggered build to complete to “end” the concurrency gate, does that sound right?
Thanks,
Toby
Hi @uh-toby,
Yes, the concurrency group label applies across pipelines within the organisation. However, for the triggering step to wait for the triggered build to complete or not depends on the value you set for the async trigger step attribute. For the use case you described, the trigger step should have async: false.
Cheers!