Deploys to an environment run one at a time

Merge 3 pull requests into main in a row, and the update workflow deploys the first to stage while the second waits. When the third arrives, it takes the second’s place in line. Stage ends up on the newest commit after 2 deploys, and a running deploy is never cancelled to get there.

Production tags queue the same way, separately from stage. If an older production run is still waiting for a reviewer, reject it so the newest one goes next.

Initialize has a queue of its own, so a push can’t take the place of an Initialize run that’s waiting.

To redo a failed or cancelled production deploy, re-run that tag’s workflow run. You don’t need a new tag. If the earlier run stopped part-way, the re-run can report success while the app stays on its previous revision, so check the live revision in Screenly afterward. If it didn’t move, push a new tag with a change to the app’s files.