Disable TeamCity build queuing

Question

Is it possible to disable queuing on builds in TeamCity? If a job is already running, I don't want another one to queue (for example, if started by a trigger). I've done some searching and do not see a way to prevent the queuing up.

Answer 1

If each is only one build configuration, you could run them on the same agent, so that way only one could run at the same time. But then, build 2 would run after build 1 finishes, which you don't want.

Here's how I solved this problem. It's kind of ugly, but it's simple, and generalizes to many build configurations:

Pick a specific server. Since this server will determine whether a build runs, we'll call it your gate server. We need a file location that doesn't exist now, nor will it be created by any other program. Say, for example, `/teamcity/.lock'

Make a build configuration with the following contents:

lockFileLocation="/teamcity/.lock"
if [ -f $lockFileLocation ];
then
    echo "oops, we're already running a build."
    exit 1
else
    echo "No build is running. Let's lock it up!"
    touch $lockFileLocation
fi

For Powershell, it's this:

$lockFileLocation = "C:\teamcity\lock"
if(Test-Path $lockFileLocation)
{
    echo "oops, we're already running a build."
    exit 1
}
else
{
    echo "No build is running. Let's lock it up!"
    echo "lock'd!" > $lockFileLocation
}

And make sure that build is set to run only on the gate agent. So this build will only succeed if it hasn't ever run. Not useful yet. Let's call this build lock. Make a new build configuration with the following contents:

lockFileLocation="/teamcity/.lock"
if [ -f $lockFileLocation ];
then
    echo "Build's over. You don't have to do home, but you can't stay here"
    rm $lockFileLocation
else
    echo "No build is running. How did we get here?"
    exit 1
fi

For Powershell:

$lockFileLocation = "C:\teamcity\lock"
if(Test-Path $lockFileLocation)
{
    echo "Build's over. You don't have to do home, but you can't stay here"        
    rm "$lockFileLocation"
}
else
{
    echo "No build is running. How did we get here?"
    exit 1
}

Make sure that build is set to run only on gate, and that build will delete the file if it exists. Let's call the build unlock.

Cool, now we can run lock to write the file, and unlock to delete it. If you run lock twice without running unlock, the first run of lock will pass, and the second will fail. Nice.

But how does this help us? Let's say that your build is a single build configuration called work. Set a finish build trigger on work so that it runs after lock succeeds. Similarly, set a finish build trigger on unlock so that it runs after work finishes, whether it passes or fails. We want to unlock the build even if you committed bad code.

If your build is a set of build configurations, your build internally needs to be connected via snapshot dependencies, and not finish build triggers. Say your build is two build configurations: work-A and work-B. You want to run work-A first, then when it's done, work-B. Set a snapshot dependency from work-B to work-A as usual. Then, set a finish build trigger on unlock that triggers when lock passes. Set a snapshot dependency from unlock to work-B, set to "run build even if dependency has failed. Here's a drawing of the build, where downward arrows are finish build triggers, and upward arrows are snapshot dependencies:

+----+                           
|lock|                           
+----+  +------+                 
  |     |work-A|                 
  |     +------+                 
  |        ^                     
  |        |                     
  |        |                      
   \   +------+                  
    \  |work-B|                  
     \ +------+                  
      \   ^                      
       \  |                      
        v |                      
       +------+                  
       |unlock|                  
       +------+                  

Now, when you hit "run" on lock, it will lock the build, trigger your build configurations, then unlock the build. Hit "run" a bunch of times, and see how neither work-A nor work-B gets queued up.

But that's only one set of build configurations. You have two. So set both of them up this way, making sure they look at the same file, and are both set to run only on the gate agent.

Yay! We're done! But wait, why do work-A and work-B need to be connected via snapshot dependencies? Well, let's say the build is as follows:

+----+
|lock|
+----+
   |
   |
   v
+------+ 
|work-A|
+------+
   |
   |
   v             
+------+
|work-B|
+------+
   |
   |
   v
+------+
|unlock|
+------+

Now, what if work-A fails? work-B won't run, and so neither will unlock.

Note: theoretically, you could run the build as follows:

+----+        
|lock|        
+----+  +------+
   \    |work-A|
    \   +------+
     \     ^
      \    |
       v   |
      +------+
      |work-B|
      +------+
         |    
         |    
         v   
      +------+
      |unlock|
      +------+

This should work, but I haven't tested it, so I can't give you all the settings.