Build Blocker Plugin

Skip to end of metadata
Go to start of metadata

Plugin Information

Plugin ID build-blocker-plugin Changes In Latest Release
Since Latest Release
Latest Release
Latest Release Date
Required Core
Dependencies
1.6 (archives)
Mar 13, 2015
1.466
Source Code
Issue Tracking
Maintainer(s)
GitHub
Open Issues
Frederik Fromm (id: ffromm)
Usage Installations 2014-Apr 1996
2014-May 2196
2014-Jun 2256
2014-Jul 2484
2014-Aug 2567
2014-Sep 2749
2014-Oct 2975
2014-Nov 3103
2014-Dec 3143
2015-Jan 3325
2015-Feb 3505
2015-Mar 3768

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)

  • Merged Pull Request #4 (Add form validation [JENKINS-27411])

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

Labels

plugin-misc plugin-misc Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Sep 02, 2012

    Shanghai Fu says:

    This plugin is very usefull to me. but I found there have a issue: For example...

    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. Apr 29, 2013

      josesa - says:

      Since you have a chain of job triggering each other you should make all jobs of ...

      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. Oct 03, 2012

    Alex Vesely says:

    Does not work for Matrix jobs. A little research showed that the plugin cannot ...

    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. Oct 03, 2012

      Alex Vesely says:

      Proposed patch: buildblocker/BlockingJobsMonitor.java public SubTask getB...

      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. Oct 03, 2012

    Mike Guiney says:

    Hi, I am also having trouble with this plugin. It seems to work fine when all j...

    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. Oct 05, 2012

    Bram Tassyns says:

    I really like the idea behind this plugin (and could really use it). However unf...

    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. May 14, 2013

    Jim Haberlin says:

    We just upgraded our build-blocker plugin to release 1.3. While the enhancement...

    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. Sep 09, 2013

    Sergey Smirnov says:

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

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

  7. Aug 20, 2014

    Trey Bohon says:

    To get this plugin to only block matches on the same node, modify BlockingJ...

    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()))

  8. Apr 03

    Mark Morris says:

    Thanks for the great plugin.  We wanted to share a modification we made to ...

    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. Apr 24

    Sven Appenrodt says:

    Whoops. Did someone noticed a change between jenkins version 1.605 and 1.610 in ...

    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();