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 AbstractBuild.java [1] but teardown is called in Build.java [2], and between these points there is the calls to setup the workspace and do the SCM checkout. [3] lines 485 - 495 of AbstractBuild.java, 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 Chris [0] https://github.com/jenkinsci/xvfb-plugin [1] https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractBuild.java#549 [2] https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/Build.java#L171 [3] https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/AbstractBuild.java#L485 [4] http://javadoc.jenkins-ci.org/hudson/model/Action.html [5] http://javadoc.jenkins-ci.org/hudson/model/InvisibleAction.html [6] http://javadoc.jenkins-ci.org/hudson/model/EnvironmentContributingAction.html On Monday, September 17, 2012 2:16:14 PM UTC+1, Zoran Regvart wrote: > > Hi, > I'm struggling to find a solution for issue reported against Xvfb > plugin (https://issues.jenkins-ci.org/browse/JENKINS-14483). 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 > configurations > > 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? > > Thanks, > > zoran > -- > Human by day user by night >
