I just merged two PRs in this order: #914, #922. next.nextstrain.org reflected the latest #922 briefly before the slower build of #914 completed and overrode the latest changes from #922.
Deploy is done as the last step of CI (which is also CD in this case). You can see that the workflows started around the same time but #914's was slower than #922's:
I think this can be difficult because the actual deploy step is quick and will not overlap in most scenarios. The overlapping happens during build but concurrency shouldn't be checked on that job – it'd still be good to have a complete build for each merged PR. Maybe having a separate build but then we wouldn't be deploying the same exact build that's being tested.
I just merged two PRs in this order: #914, #922. next.nextstrain.org reflected the latest #922 briefly before the slower build of #914 completed and overrode the latest changes from #922.
Deploy is done as the last step of CI (which is also CD in this case). You can see that the workflows started around the same time but #914's was slower than #922's:
Possible solutions
jobs.<job_id>.concurrencydeploystep is quick and will not overlap in most scenarios. The overlapping happens duringbuildbut concurrency shouldn't be checked on that job – it'd still be good to have a complete build for each merged PR. Maybe having a separatebuildbut then we wouldn't be deploying the same exact build that's being tested.