Chris, thank you very much, this helps a lot ;) zoran
On Mon, Sep 17, 2012 at 6:30 PM, cjo <[email protected]> wrote: > 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 -- Human by day user by night
