Hi.In our company's development environment, we have 7 slaves running over 150 jobs on Jenkins. We used to assign each job to a specific slave in the past, but we made a recent change where we let Jenkins decide which slave to run jobs on through the label function. However, after switching to this setup, we ran into a problem: we had downstream jobs that needed to be run on the same slave and same workspace as the upstream job, but now there was no way of restricting them to run on the same slave. We resolved this issue by using the Parameterized Trigger Plugin, which includes a 'build on the same node' option, which when combined with Jenkins' 'use custom workspace' gave us the functionality we needed.
This solution works fine when the downstream job is triggered by the upstream job, but due to the need for Parameterized Trigger Plugins 'build on the same node' option, we lost the ability to start any downstream jobs on their own, as they could not find the correct slave to run on. In our case, each upstream job can take an hour to run, so this means we lose an extra hour each time we just need a downstream job to run.
We believe jobs needing to share a workspace is a fairly generic scenario and clusters of slaves are common. When these two generic use cases happened together, we lost flexibility. This is why we took the initiative to develop a plugin which could resolve this issue.
The plugin is titled Node Stalker and enables a job to be configured to build on the same node, and if desired, the same workspace as another job. The plugin is fully unit tested and documented, is copyrighted under the MIT License and has been deployed to our development Jenkins. Here are unit test coverage statistics from Sonar and a link to the plugins source code on Github:
cid:[email protected] https://github.com/fneves-datalex/job-node-stalker/The plugin is very useful in common cases such as certain jobs which need to be run on the same workspace as another job, the generic nature of it means that it increases user options in a variety of situations. Other plugins such as the Parameterized Trigger plugin include a 'build on same node' or 'share workspace' option, however the job needs to be launched by the job it wants to follow in these cases, which limits user choice in choosing the best workflow for their situation. One other thing to mention is that our Node Stalker plugin works very well in conjunction with the Prerequisite build step plugin, as Node Stalker currently has no way of ensuring that the job it is following is not currently in progress or failing, which the Prerequisite build step plugin can check for before letting a job start.
We would like to contribute this to the Jenkins open source community and would appreciate if we could host our plugin on Jenkins repository and the plugins section of the Jenkins site. Following the instructions on https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins, we have added all necessary information into the POM and made a wiki page for the plugin (https://wiki.jenkins-ci.org/display/JENKINS/Node+Stalker+Plugin). Please let me know if there is anything else to be done before releasing the plugin on Jenkins CI.
Thanks in advance, Fabio Neves & Baris Batiege (Datalex) -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
<<image/png>>
