Fix proposal for using build-blocker-plugin with more than one exectuor. #1
Conversation
Alex Vesely (1990.alex@gmail.com): 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.
Bram Tassyns (bramt@enfocus.com): Currently the core of this test is still uncommented. This will be uncommented after the actual fix.
Bram Tassyns (bramt@enfocus.com): If there is more then one executable then it is not sufficient to check the executors, you should also look at the Queue to determine which jobs will be executed next. Enabled to unit tester for this case as well.
Bram Tassyns: A job should never check its own name to determine if it should be blocked.
Use the correct way to add JUnit tests.
|
Jenkins » build-blocker-plugin #2 SUCCESS |
|
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 there many changes 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? |
Hi, we exchanged mails a while ago about an issue in this plugin and that you didn't have time to look at it. I didn't get much time either so it took a while, but I finally have a proposal for a fix + some test cases for it.
Note that I'm not a java developer and its my first time working with maven, Jenkins API and JUnit testing so please read it through carefully.