BuildWrappers and matrix jobs

Skip to first unread message

Zoran Regvart

Sep 17, 2012, 9:15:51 AM9/17/12
I'm struggling to find a solution for issue reported against Xvfb
plugin ( I cannot
seem to find a solution that works both concurrently: so each matrix
job doesn't overwrite process handle, and assuredly: so that all
started Xvfb processes are terminated in the end.

Things that seemed to work but actually did not:
- starting Xvfb process only for MatrixJob build instances - ended up
overwriting process handle stored in the descriptor of the build
wrapper, so in tearDown of substituted Environment only the last
started process would be terminated
- starting Xvfb process for MatrixBuild build instances, counting the
number of MatrixJobs and decrementing the count in tearDown so when
the count reaches 0 it's safe to terminate Xvfb - ended up not working
(of course) too well for distributed master-slave Jenkins

I must be missing something here, is there no way to wrap each
MatrixJob with it's own instance of BuildWrapper? If not is there a
place I can store and later retrieve the process handle, or must I use
a map to track my process handle variable with each matrix job -- the
only thing I can think of that would sort-of work?


Human by day user by night


Sep 17, 2012, 12:30:41 PM9/17/12
Just had a quick look at the code in github for the plugin [0] and can see a couple of problems in additionto the one mentioned and some possible solutions.
Issues that I can see:
1. The process can be started in decorate launcher, but the build can be aborted by other properties/workspace allocation before the build is started to be run, therefor the Enviroment setup,teardown are not called.
As decorateLauncher is called at [1] but teardown is called in [2], and between these points there is the calls to setup the workspace and do the SCM checkout.
[3] lines 485 - 495 of, which can all abort the build.
2. You only store one process item, main issue of JENKINS-14483.
3. Possible issues if multiple configurations run on the same node using the same displayName

Possible solutions:
1. Move the process creation into the setup method (via a private method). Solves the issue that build could be cancelled before teardown is called.

2a. Store the process information as a subclass of InvisibleAction [4][5], - in this case your Environment will need to get the action from the build to use in buildEnvVars(). but it does not have a reference to it.
2b. Store the process information as a subclass of EnvironmentContributingAction [4][6], setting the getDisplayName, getURL, getIcon to return empty string or null to remove the UI.
In this case this action would implement buildEnvVars() rather than the Environment object.

Add this action to the build in the public Environment setUp() call,(build.getActions().add(<yourAction>) and fetch it during teardown( List<> = build.getActions(<yourAction.Class>) ) to terminate the process started.
As the actions are not passed from matrix parent to matrix configurations (unless implementing MatrixChildAction) these will be unique for each configuration run.

3. The reuse of display names for different configurations on the same node may or may not be an issue, but in this case you could executor number of the slave to make it unique ( build.getExecutor().getNumber() )

These are ideas that should fix the issues you are seeing.

Hope this helps

Zoran Regvart

Sep 18, 2012, 2:41:54 AM9/18/12
to cjo,
thank you very much, this helps a lot ;)

Reply all
Reply to author
0 new messages