Enforce Job Queuing [Run only on one build at a time]


#1

We would like to have the ability to enforce queuing in jobs.

Mark a job with enforce_queuing will enforce that only one job can run at any time, and if another build triggers the same job, the job will queue until the other build is finished.

This feature could be handy for continues deployment where we want to guarantee that only one deploy is being run at any given time.

For example, after we merge to master, we would like to make sure that no other deploy jobs will run until the currently running one is finished.

workflows:
   jobs:
      -build
      - deploy:
         enforce_queuing: true
         filter:
           branches:
             only: master
         requires:
             - build

#2

Same need here.


#3

Same need here. Is there any way to accomplish this?


#4

Looking for the same feature.

Any other workaround to have this?


#5

Looking for this feature too. Is there any updates on this? Or any workaround?


#6

To do this, I reckon you need your build server to record state. You’d first test a flag to see if a build is in progress, and if it is, exit early. If it is not, write that flag to say a build is in progress, and unset it at the end.

In general, build servers don’t record state, since the whole point is they are clean every time they run. However, you still have a few options to read/write this flag:

  • (Mis)use the CircleCI cache feature
  • Read/write the latest commit in a separate Git repo created for the purpose
  • Connect to a remote file space e.g. via scp

Can you whip up something on that basis, using some shell scripting?


#7

This is the opposite of what I want though. I want the second build to run after the first, but this would stop the second build. I could wait for the flag in the second job, but then I am still taking up a container that is just waiting. Ultimately, I want the build system to Queue my second job, I don’t know if there is any way of faking that though, it needs to be part of the system.

The other option is this: "Auto-cancel redundant builds" not working for Workflow

That would work too, but is less clean. If a build is randomly cancelled because another one starts, it could leave things in a potentially bad state. Not on the container, which I don’t care about, but if I was in the middle of uploading a bunch of files somewhere, or something of that nature. But it would still give us the same goal.

Basically, if I have a 30 minute job and I am on the 2 container plan, I don’t want both my containers used for 30 minutes if two people check in at almost the same time. That is the overarching requirement, to have that job run only once or at least one at a time.


#8

Ah, I beg your pardon. I saw the title, and assumed it was about preventing a deployment from happening again if a trigger occurred during a previous build (which might break a deployment). Essentially my approach was about cancelling the second job, but you want yours to queue.

OK, well there is a very hacky solution - not sure if it would be brittle though:

  • Implement my idea, but with a small modification - if a collision is detected, set another flag to say that a build is due
  • Also create a scheduled build to check for the second flag (e.g. every ten minutes). If this is set but the first one isn’t, this means that a collision has been detected and the first build has finished, and you can use this as a trigger to kick off a new build. (If both flags are set, it means a collision has been detected but the first build hasn’t completed yet).

Also, if that sounds like it might be too fragile, there’s a build API which might give you some historical build information. Using that on a cron may be helpful as well - dunno.


#9

I can see that working, but definitely seems fragile. There is a simpler solution in the “Auto-cancel…” thread that basically says to use the API to cancel the first build. So setup a webhook and listen for checkins, then poll Circle for any jobs running from the repo and cancel them if you find any. It is simpler, but like I mentioned before, not as clean.

I still think this would be a valuable feature as part of the framework. Other tools I have used allow one build of one project to run at a time. It prevents a whole host of issues, such as the first deployment that completes wins, even if it was the first (older checkin) job. From a deployment perspective, it makes a lot of sense.

I don’t plan to open a feature for it, though. I think the “Auto-cancel” feature would be ok with us and I don’t want to cloud that one. So I put my vote to that one and hope it will be implemented. In the short term, I can use the API as mentioned above to force the feature if I want.


#10