My deploy on Google Cloud (app engine flexible) takes about 12 minutes to complete, and deploying with zero downtime requires using their API to spin up an alternate then swap it in once healthy.
If any additional commits to our staging or release branches trigger a build in that time they will fail with an error in the deploy phase.
I’d really like a way to stop those build errors because they’re distracting the team and are totally avoidable. Circle already allows earlier builds to be auto-cancelled by subsequent commits to a branch, but since that could interrupt a deployment that doesn’t work here. Instead I need builds to be queued until the deployment is complete and the branch is ready.
Appreciate that this has already been raised twice over the past 3 years, but replies seem to be disabled on those threads so I want to voice my support for it.
I agree with need generally. Queuing subsequent builds and cancelling previous builds are not the same thing. So I would argue that only one of the feature requests you linked to was actually “solved”.
A feature I love in ahem other tools, is the build concurrency limit so it let’s every build run, validate it didn’t break anything, and will just queue any further builds. The “auto-cancel” leaves some commits potentially untested, and blamed on subsequent commits.
I use Cloud Foundry blue/green, the delay is only ~2-4 minutes, and was thinking about using some scripting logic to just block the start of deployments if any previous builds are running.
https://circleci.com/api/v1.1/project/:vcs/:username/:project?filter=running could detect all running builds for a project. You’d have to add some logic to only proceed if any returned results are >= to current ID.
As a workaround while native options might be considered…
I’ve released versions of common Convenience Images that add a new command. The single command queueBuildUntilFrontOfLine 10 is a blocking operation that will inspect the list of all running builds for the project, and only move forward when all previous builds complete. It can be used only in the jobs (like deployments) that must be isolated.
The single argument is max # of minutes to wait before aborting current job (previously running job allowed to continue).
I started with jdk-8, node-4, and python-2.7 - happy to add any other images provided by circleCI.