Deploy commits sequentially instead of canceling ongoing builds for new commits.
planned
K
Kai Marshland
I would like to be able to have multiple deploys running at once. Let's say deploys take 10 minutes, and I deploy Version A at 6:15pm, and Version B at 6:20. With the current behaviour, it would deploy Version B at 6:30, canceling the deploy of A. I would like to be able to have Version A running from 6:25-6:30, then Version B from 6:30 onwards.
Log In
A
Angelina Quach
this is extremely helpful, so that we can determine which specific commit caused an error and handle rollback accordingly. Batching commits causes debugging ambiguity, especially in a CI/CD env.
Anurag Goel
Ultimately, the issue posted here is that long builds get canceled when a new commit hits and auto deploy is on, and you might not have the latest version deployed for a while if you're committing frequently.
One way to tackle this is to let an existing deploy finish, and once it does, pull the latest commit and start deploying it instead. Kai Marshland does that work for you?
K
Kai Marshland
Anurag Goel: That'd get 70% of the way there in my mind. Definitely better than the status quo, but not perfect either
A
Adam Neary
Anurag Goel: Per our side conversation, it sounds like this behavior might want some configurability so that teams can tweak to their own needs. We probably wouldn't want many production builds happening in parallel, so for our particular case the scenario you're describing above sounds ideal, whereas it sounds like Kai would rather have them running in parallel. Not sure how tricky it would be to deliver on both modes?
Anurag Goel
planned
Y
Yashu Mittal
We can define it with term call “Concurrent build”.