Using Build Flow to run a test using two machines

2013-10-15 Thread teilo
There is a commercial plugin from cloudbees that will allow you to do this with 
VMware.

A single job can have multiple VMs assigned on which you can run commands like 
starting your server and then starting your client.

There are possibly other ways but I have not used them.

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Using Build Flow to run a test using two machines

2013-10-10 Thread Jeremy Morton
My high-level scenario is that I have a pool of slave machines that I want 
to run tests on, but I need to use two machines for each run [one acting as 
a client, one acting as a server]. I would like to have it choose two 
machines from the pool and then run the tests on them, keeping other test 
runs from using those two machines while they are in use for the first run.
 
I have set up a main build flow job that kicks off a server build flow job, 
which it captures the results of in order to know the machine name of the 
server for the run. It also kicks off a client job in parallel that takes 
the server machine name as a parameter in order to interact with it.
 
I use the Throttle Concurrent Builds option to restrict the main build flow 
and the server build flow jobs to only running 1 concurrent build per node 
[they are in the same category]. This prevents these jobs from running on a 
node that already has one of them running on it.
 
The main build flow job looks essentially like this now:
 
def serverResult
def clientResult
 
def serverBuildFlow = {
  serverResult = build(
 'ServerBuildFlow',
  BUILD_CHANGELIST: params['BUILD_CHANGELIST'],
TEST_SUITE: params['TEST_SUITE'],
BRANCH: params['BRANCH']
  )
}
def clientBuildFlow = {
  clientResult = build(
  'Client',
  BUILD_CHANGELIST: params['BUILD_CHANGELIST'],
   RUN_ON_NODE: build.properties['builtOnStr'],
TEST_SUITE: params['TEST_SUITE'],
   SERVER_NODE: 
serverResult.build.properties['builtOnStr'],
BRANCH: params['BRANCH']
  )
}
guard {
  parallel (
serverBuildFlow,
clientBuildFlow
  )
} rescue {
  build(
 'Cleanup',
   RUN_ON_NODE: build.properties['builtOnStr'],
  BUILD_CHANGELIST: params['BUILD_CHANGELIST'],
TEST_SUITE: params['TEST_SUITE'],
   SERVER_NODE: 
serverResult.build.properties['builtOnStr'],
BRANCH: params['BRANCH']
  )
}
 
It has two shortcomings:

   1. The ServerBuildFlow job starts up the server components and then the 
   job finishes. This then allows another job to be scheduled on the server 
   node, which is completely disruptive. I need the server build flow job to 
   continue running until the client is done with the server, then I need it 
   to end, so that the machine is freed up to be a client or server again.
   2. Because the server build flow job and the client job are started in 
   parallel, the client job isn't picking up 
   serverResult.build.properties['builtOnStr'], which it needs to know in 
   order to connect to the appropriate server machine. Because the server 
   build flow job needs to be running for the entire duration, and otherwise 
   the client job doesn't need to wait for the server build flow job, I have 
   them running in parallel.

Any ideas on how to address these two issues, or just accomplish my 
high-level goal in another fashion?
 
Thanks,
Jeremy

-- 
You received this message because you are subscribed to the Google Groups 
Jenkins Users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.