Skip to end of metadata
Go to start of metadata

Plugin Information

View Build Blocker on the plugin site for more information.

This plugin keeps the actual job in the queue if at least one name of currently running jobs is matching with one of the given regular expressions.

General

This plugin is similar to the locks and latches plugin. The main difference is, that it uses regular expressions to find potentially blocking jobs by their names in the list of currently running builds. It uses the QueueTaskDispatcher to check if the actual job may be build. The dispatcher uses the list of regular expressions configured in the job. If one of the currently running jobs matches with one of the regular expressions, the job stays in the queue.

How to use

After installing the plugin, the job configuration page has a new property "Block build if certain jobs are running" in the upper section.

Insert one regular expression per line into the textarea. Each expression is used to detect currently running jobs that match with their names. The first matching job name will block the build and the job will stay in the queue until all expression are evaluated without match.

Other than the locks and latches plugin where both, the job to be build and the blocking job, need to have the same lock configured, this plugin allows to just configure to job to be build. No jenkins system configuration is needed.

Version history

1.1 (June 24, 2012)

  • Initial commit.

1.2 (June 25, 2012)

  • Added wiki url to pom.

1.3 (January 8, 2013)

Merged pull request of bramtassyns (https://github.com/jenkinsci/build-blocker-plugin/pull/1) - Thanks for the great work!:

  • FIX to work with matrix jobs
  • jobs running and - new - in queue with matching names block the current job's start

1.4.1 (June 28, 2013)

  • added "executors.addAll(computer.getOneOffExecutors());" to get a build blocked by all Multi-Configuration-Job executions. Now a blocked build starts AFTER the whole blocking matrix build and not in the middle of it. ATTENTION: With Jenkins version 1.447 the blocked job got stuck in the queue. Now the plugin requires Jenkins version 1.466 to run.

1.5 (March 13, 2015)

  • Merged Pull Requests #2 (Added support for the Folders plugin) and #3 (Regex validation JENKINS-27402)

1.6 (March 13, 2015)

1.7 (July 1, 2015)

  • Merge Pull Request #5 and #6 (avoid NPE and extended to block on node level and to scan the queue for builds in all states)

1.7.1 (July 3, 2015)

  • Fixed NPE when using existing build blocker config not having the new properties.

1.7.2 (November 24, 2015)

  • merged Pull Request # 7 FIXED JENKINS-29924 Items with non-AbstractProjects tasks block the build queue

1.7.3 (December 14, 2015)

  • merged Pull Request # 8 FIXED JENKINS-29924 Transform AbstractProject into Job for Workflow compatibility

The blocking behaviour can be configured to either block builds

from running on the same node
from running at all
Additionally, the blocking behaviour can be configured to consider planned, but not yet running builds in the decision to block a build. Either

buildable builds can stop another build from running (for instance builds that are waiting for an available executor)
all planned builds can stop another build from running (blocked builds, pending builds waiting builds and buildable builds)

TODOs

  • Block a build by all sub-execution of a matrix job build, not only the first one.
  • Make blocking by items im Queue optional (default on). There may be situations, where regarding the items in the Queue that are not yet in execution may lead in a dead lock.
  • Add information of duration blocked to comment in Queue.
  • Add optional functionality to Keep only the last item of a job in queue.
  • Add Slicer for Configuration Slicing Plugin

30 Comments

  1. This plugin is very usefull to me.

    but I found there have a issue:

    For example: My build include 4 jenkins job, the sequense is:  Build_A -> Build_B -> Build_C -> Build_D.

    I configure the blocker '.*Build_.*' in 'Build_A', I want to start the Build_A after all follow job (B, C and D) complete.

    But the actual sequense is:

    1. Build_B is running...

    2.  Trigger Build_A by manual

    3. Build_A is pending....

    4. Build_B done

    Build_A start running in incorrect (Actually I want Build_A start after all follow jobs done.)

    5. Build_C start running.

    ......

    Did you have any solution? thanks in advance.

    1. Since you have a chain of job triggering each other you should make all jobs of the chain wait for any downstream jobs (expand Advanced project options and enable "Block build when downstream project is building")

  2. Does not work for Matrix jobs.

    A little research showed that the plugin cannot get the names of matrix jobs correctly. Apparently, subTask.getDisplayName() returns the label name instead of the job name. So If I put '.*' into the blocking job list (to block on anything), I get the message: "Blocking job Linux is running", where Linux is the label name, not the job name.

    1. Proposed patch:

      buildblocker/BlockingJobsMonitor.java
          public SubTask getBlockingJob() {
              if(this.blockingJobs == null) {
                  return null;
              }
      
              Computer[] computers = Jenkins.getInstance().getComputers();
      
              for (Computer computer : computers) {
                  List<Executor> executors = computer.getExecutors();
      
                  for (Executor executor : executors) {
                      if(executor.isBusy()) {
                          Queue.Executable currentExecutable = executor.getCurrentExecutable();
      
                          SubTask subTask = currentExecutable.getParent();
                          Queue.Task task = subTask.getOwnerTask();
      
                          for (String blockingJob : this.blockingJobs) {
                              if(task.getFullDisplayName().matches(blockingJob)) {
                                  return subTask;
                              }
                          }
                      }
                  }
              }
      
              return null;
          }
      
  3. Hi,

    I am also having trouble with this plugin. It seems to work fine when all jobs are running on the master node. I need to block jobs that are running on a slave node (i.e. on a different queue). Maybe this suggested patch will help.

    regards,

    Mike

  4. I really like the idea behind this plugin (and could really use it).
    However unfortunately it doesn't work when you have more then one executor.
    If you have 2 queued builds (that are waiting for blocking job) and 2 open executors,
    when the blocking job finishes, both items get scheduled (even if they lock each other out).

    I think this could be prevented by for example assuming that after canTry returns a null value, that job is considered as being executed for X seconds (even when its not yet actually inside an executor).

  5. We just upgraded our build-blocker plugin to release 1.3.

    While the enhancement for multiple jobs is definitely an improvement, there may still be an issue, or maybe there is another way around the issue I am experiencing. I have separate compile and deploy jobs, each have the other as a blocking job. If the compile job is running and another compile gets submitted (including from an SVN polling job) the second job goes into queue as expected. If the deploy job is submitted that also goes into queue, which is also expected. The problem is if more compile jobs get submitted they are getting priority over the deploy jobs. I was hoping the jobs would run in the order that they were submitted, but that does not appear to be the case.

    In my situation, build jobs get submitted whenever code changes are committed by a developer (so we can be notified of any compile issues) but the deploy jobs are submitted manually (so testing will not be interrupted by the server being restarted without notice). Unfortunately if many changes are being committed then many build jobs can get queued and the deploy job will not run until ALL of the queued build jobs have finished. Is there a way to control the priority so that it starts the queued jobs based on time submitted? Is it possible to limit how many times a specific job can be in the queue?

  6. Is it possible to add plugin parameter "Block only if job run on the same slave"?

  7. To get this plugin to only block matches on the same node, modify BlockingJobsMonitor.java to:

    for (Computer computer : computers) {
       String NodeName = computer.getNode().getNodeName();
       if(NodeName.equals(item.getAssignedLabel().getName()))

    1. This would be nice to have as a checkbox option under the regex-text-field when using the plugin from Jenkins.

  8. Thanks for the great plugin.  We wanted to share a modification we made to it that allows us to block by priority.  We were having an issue when using the Build Blocker plugin with the Priority Sorter Plugin (basically lower priority jobs were still allowed to build if a higher-priority job was being blocked) so we created a modified version of the Build Blocker plugin to resolve that.  We call it the Priority Blocker Plugin (PriorityBlockerPlugin.zip) and you basically just define a job's priority and it will guarantee the higher priority jobs get built first.  This plugin is a modified copy of the Build Blocker Plugin so we thought we'd just present it here in case you felt like it was worth including.  Attached is the source and in-house documentation and here is the relevant code section from the BlockingPriorityMonitor class (posted with permission from Monster Worldwide Inc)

     public static SubTask getHigherPriorityPendingJob(Queue.Item currentItem, int currentItemPriority) {
        
        /*
         * check the items in the queue
         */
        Queue.Item[] queueItems = Queue.getInstance().getItems();
        for(Queue.Item queueItem:queueItems){
          if(currentItem != queueItem){
            AbstractProject<?, ?> project = (AbstractProject<?, ?>)queueItem.task;
            BuildBlockerProperty queueItemBlockerProperty = project.getProperty(BuildBlockerProperty.class);
            if(queueItemBlockerProperty!=null){
              if(currentItemPriority > queueItemBlockerProperty.getPriority()){
                return project;
              }
            }
          }
    

    PriorityBlockerPlugin.zip

    Thanks,

    Mark Morris.

  9. Whoops. Did someone noticed a change between jenkins version 1.605 and 1.610 in the executors.
    Using a builldflow plugin and spawning multiple parallel actions which are launching jobs drops some of them. And in the logs i can see the following exception.

    java.lang.NullPointerException
    	at hudson.plugins.buildblocker.BlockingJobsMonitor.getBlockingJob(BlockingJobsMonitor.java:84)
    	at hudson.plugins.buildblocker.BuildBlockerQueueTaskDispatcher.canRun(BuildBlockerQueueTaskDispatcher.java:79)
    	at hudson.model.Queue.isBuildBlocked(Queue.java:1110)
    	at hudson.model.Queue.maintain(Queue.java:1320)
    	at hudson.model.Queue$MaintainTask.doRun(Queue.java:2450)
    	at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:51)
    	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
    	at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
    	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
    	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
    	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
    	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
    	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    	at java.lang.Thread.run(Thread.java:662)
    

    It seems even after asking an executor for beeing busy, the current executeable can be null...

    Queue.Executable currentExecutable = executor.getCurrentExecutable();
    
  10. After upgrading to Jenkins 1.612 (from 1.608) jobs in Build Queue have started to block each other (all the jobs having the same regexp; in my setup .deploy-uat.).

    With multiple jobs in the Queue, the Executor doesn't pick anything from the Queue. If I remove all jobs but one from the Queue, the Executor picks it up directly.

    It seems the check is done not only against the jobs currently executed by the Executor but also against all the jobs in the Build Queue.

  11. I have the same experience as Lars that Build Blocker blocks if building or queued.   I wonder if related to an underlying change in core jenkins.  I have a number of jobs in a stream relationship.  I have one system on Jenkins 1.530.  Despite the box saying "Block build when downstream project is building", the pop-up help says "queued, or building".  However, in 1.530 it truly only blocks if building.  I have another jenkins that I upgraded to 1.611.  In that system, that same check box now block if queued or building (as the help says, but not what was implemented in 1.530).  I had downloaded the build-blocker plugin as I wanted to block builds that were not in a stream relationship.  When I later encountered the stream "queued" difference of 1.611, I tried to change it to use the Build Blocker since its help says just "building".  However, a simple test shows it's both building and queued.   I really need one that only blocks on building -- if 2 or more in the relationship are queued, just pick one.  Seems like the definition of Build Blocker is that it should not block on queued.  So would be nice if it could be changed to operate as described.  Alternatively, I'm open to other plugins/techniques if someone has a suggestion.

  12. I have the same experience as Lars that Build Blocker blocks if building or queued.   I wonder if related to an underlying change in core jenkins.  I have a number of jobs in a stream relationship.  I have one system on Jenkins 1.530.  Despite the box saying "Block build when downstream project is building", the pop-up help says "queued, or building".  However, in 1.530 it truly only blocks if building.  I have another jenkins that I upgraded to 1.611.  In that system, that same check box now block if queued or building (as the help says, but not what was implemented in 1.530).  I had downloaded the build-blocker plugin as I wanted to block builds that were not in a stream relationship.  When I later encountered the stream "queued" difference of 1.611, I tried to change it to use the Build Blocker since its help says just "building".  However, a simple test shows it's both building and queued.   I really need one that only blocks on building -- if 2 or more in the relationship are queued, just pick one.  Seems like the definition of Build Blocker is that it should not block on queued.  So would be nice if it could be changed to operate as described.  Alternatively, I'm open to other plugins/techniques if someone has a suggestion.

  13. Yes the new way of how the Build Blocker works is not working for us. We use the blocker to block a set up projects and when one finishes up it should just pick the one next from the queue that was blocked, instead it just dead locks.

    If this is really the intend - than either I am looking for a new plugin or have an options added to restore the old way of blocking.

  14. I have a potential deadlocking scenario and want to know if this will happen with this plugin:

    I have Job A which runs Jobs B, C and D. Job B can run on its own and frequently, it does. Jobs C and D never run unless they're are called by Job A and Job A is only finished when the Jobs that it initiates (B, C, D) finish.

    I don't want Job B to run on its own if Job A is already in progress. However would this prevent Job A from kicking off Job B, since it needs to run B, C, D as "sub-jobs"?

    1. For anyone who is curious, I have confirmed that a deadlock would occur. Is there a plugin like this where the rules are in reverse. That is, instead of blocking the current job if a blocker job is running, the blocker job would specify which jobs to queue up.

  15. I tried a scenario with A, B, C & D.  I set the Build Blocker setting to not run A if B, C or D running.   Thus, B, C & D set to not run if A running.   I then started A and, while A was running, hit "Build Now" on B.  Naturally it queued.  When A finished, it started C & D.  While A would have queued B, it was apparently intelligent enough to just run the B that was already queued.  So in this case, Build Blocker seemed OK.  The only thing I was unsure of was the statement that A not done until B,C & D finished.  So is there something that A needs to do after they finish?  If so, I'd suggest adding a job E that C (or D) starts.   Job E would not run if B, C or D running.  It would then "finish A".

    1. Hey Douglas,

      Thanks for the reply. In my case Job A is a build flow job that sequentially kicks off other jobs and waits for them to finish before moving on the next job. Since B will not run if A is running and A is running at the time that it kicks off B, B would be queued up and wait eternally for A to finish but A would never finish because it is waiting B to finish.

  16. Does anyone have more advanced regex examples? I tried adding one with spaces (escaping them) but doesn't seem to want to work. Using Jenkins 2.16

  17. Hi,

    is it possible to use this plugin with Multibranch Pipeline jobs?

    1. You can use the properties() call:

      properties([
          [$class: 'BuildBlockerProperty',
           blockLevel: 'NODE',
           blockingJobs: '^python3 \\(pipeline\\)/.*',
           scanQueueFor: 'ALL',
           useBuildBlocker: true],
         disableConcurrentBuilds()
         ])

       

      Here, I set some job properties, including the one for BuildBlocker plugin.

      1. Silly question, but how would you use this in a "Declarative" pipeline?

        1. Do you have an answer to this question now?

        2. Alex Gray I'm also curious if there is a possibility to use it in a declarative pipeline... Did you find an answer?

          1. Patrick Hawk , Unfortunately, I do not. I did not find a way to solve this.

  18. It would be very useful if there could be also parameters checked additionally to job names. Means if job A runs with parameter SERVER=X then other jobs with parameter SERVER=X must wait.

    It can be probably done with adding optional regex for checking parameters names and its values.

    Maybe even more flexibility would bring the option to execute (system) groovy script which returns boolean result to inform if job can be started or not. In groovy script we can handle whatever logic we like, job parameters, nodes...

  19. I am writing a Jenkins DSL script (groovy) that will create a Jenkins Job. One of the options I would like the job to have enabled is the box that reads "Block build if certain jobs are running"

    I tried to use the "blockOn" code that I found here: https://jenkinsci.github.io/job-dsl-plugin/#path/freeStyleJob-blockOn

    But when I run my DSL script the job gets created and does NOT have the "Block build if certain jobs are running" box checked

    Below is the entire DSL script that gets executed:

    job('Testing-DSL') {
      blockOn(['2.Dummy_job', '1 .Dummy_job']) {
        blockLevel('GLOBAL')
        scanQueueFor('ALL')
    } //closing blockOn section
    
          description('''\
    This is just a template job that I use to reference how groovy code should look<br>
     ''')
    
    logRotator(-1, 30, -1, -1)
    
    parameters {
        choiceParam('CHOICE1', ['choice_option1', 'option2'], 'Some description for this param')
        stringParam('STRING1', 'Default_Value_string1', 'Some description for this option')
    
    } //closing parameters section
    
        steps {
        shell('''\
    echo $CHOICE1
    echo $STRING1
    ''')
    
    } //closing steps section
    } //closing job section
    1. How embarrassing.  I had just installed the plugin without a restart.  Restarted Jenkins all is well.

Write a comment…