Sounds like something that would be quite useful. Be sure to deadlocks you implement this. On Feb 27, 2012 4:00 PM, "James Mulcahy" <[email protected]> wrote:
> Hello, > > I'm considering creating a plugin to solve a problem that I don't > believe I can solve with any existing mechanisms. If my assumptions > here are wrong, I'd be grateful if someone can point out which > plugin(s) I should more closely examine. > > I would like to be able to run jobs on the master node (or perhaps on > a slave, but lets keep this simple for now), and have those jobs have > the use of a slave, or a number of slaves. Note, I do not want to run > the job directly on the slave. The use case for this is where a job > requires some hardware or resources that perhaps has little resource, > but is required to perform some tests on a build. I can imagine that > using say, a bunch of iPhones in this manner might be a common use > case, another might be some sort of load generation machine (such as > an IXIA network packet generator) where there can only be one "user" > at a time. > > I currently envisage a plugin which adds an additional build step > which is to reserve slaves. It would allow the job to specify (label, > quantity) tuples -- indicating how many of each type of slave should > be reserved. In performing this build step, an executor on a slave > would be reserved. > > Later build steps would then be able to use these slaves for whichever > purpose they choose. Exporting information to latter build steps > would probably have to be done through the environment -- though I'm > keen on alternate suggestions. Scripts could then read the > environment variables (which would include the labels, slave names/ > hostnames) and use those slaves as they wish. > > I've not written a Jenkins plugin before -- though I'm happy to give > this a shot. I've trawled the wiki and looked for some relevant > extension points, but aside from the Environment hook, I'm not really > sure where else to hook in. > > If anyone has any thoughts or views on this proposal, I'd welcome them > -- both from an approach/use-case perspective, but also in terms of > implementation. > > Cheers, > > --James > > >
