Thanks Dean, I sincerely appreciate the reply. I am not sure what you mean by @N notation. Maybe this will help me improve my build-environment. (I will google it )
I like to have this behaviour to be configurable by the user. The reason is that I have a main (parent) project that has this checkbox set, but its downstream (child) projects do not. The parent job sets the workspace for the build, gets the src from the SCM, and passes it on to the other jobs to compile, test,etc.... The child downstream projects just get the workspace directory as a parameter and perform their task(i.e. compile,test). I have a set of jobs where each one only performs a specific task on a given workspace (i.e.compile,test,etc...). Each one does not care about the SCM nor any other project details. It just gets a workspace dir to perform+report its work and away it goes. The beauty of this is that All of these downstream jobs are concurrently running across 10 build and test machines. Each one acting on a workspace. In some cases I am compiling build-targets on the same workspace dir at the same time from different machines. The compile targets do not conflict with each other, and I save a lot of time. I also re-use these donwstream jobs for different SCM branches. Using the MultiJob plugin allows the main (parent) upstream project to know when all of its requested compiles and testing has finished. I hope that this makes sense. Thanks, Marek Gimza On Fri, Sep 21, 2012 at 4:31 PM, Dean Yu <[email protected]> wrote: > To summarize, the problem that you have is that when your project is > configured with both a custom workspace and to perform concurrent builds, > the same path is used by all the builds, causing them to step on each > other. Is that correct? > > If this is the case, is there ever a case where you don't want to use the > @N notation in this situation? In other words, why not just make this > always be the behavior instead of having to require the user to configure > it? > > -- Dean > > From: mgimza <[email protected]> > Reply-To: "[email protected]" <[email protected] > > > Date: Thursday, September 20, 2012 2:28 PM > To: "[email protected]" <[email protected]> > Subject: Checkbox to allow the Custom Workspace be shared among different > slaves. > > > I would like to share a change I have made to the jenkins-core that > introduces a new checkbox called customWorkspaceRoot to a job configuration. > > Please find attached a GIF file showing the CustomWorkspace path and > checkbox setting in a job's configuration page. > > > Objective > ======== > To let Jenkins use the CustomWorkspace path (set in a Job's configuration > page) in the same manner as the "Remote FS root" path that is set in the > Node's configuration page. > > Normally the customWorkspace is static, in the sense that Jenkins does not > alter the workspace path for different concurrently running instances of > the same job. > The intent of this code-change is to be able to allow Jenkins to run the > same job multiple times, where the CustomWorkspace path is used to create a > unique workspace path for each concurrently running instance of the same > Job. > > > For example: > ----------------------- > Scenario 1. Normally when the customWorkspace is NOT set, the selected > Node's "Remote FS root" path is used for each concurrently running instance > of the job: > job1 - /Nodes/path/job > job2 - /Nodes/path/job@2 > job3 - /Nodes/path/job@3 > etc... > > > Scenario 2. Normally when the customWorkspace is set, the 'same' > customWorkspace path is used for each concurrently running instance of the > job: > job1 - /Nodes/path/job > job2 - /Nodes/path/job > job3 - /Nodes/path/job > etc... > > > > Scenario 3. In scenario 2, the same path is used, causing the jobs to > overwrite each other.. This code change introduces scenario 3: > When the customWorkspace is set AND the new checkbox called > customWorkspaceRoot is also set, the customWorkspace path is used for each > concurrently running instance of the job as follows: > job1 - /Nodes/path/job > job2 - /Nodes/path/job@2 > job3 - /Nodes/path/job@3 > etc... > > > > Purpose/Advantage > =============== > To allow a job to share its workspace path with its downstream projects, > where the downstream projects can run from any slave and not be mandated to > run on the same machine as its parent upstream project. > > notes: > --------- > The workspace is passed to the downstream projects as a parameter. > The workspace must be on a shared disk that is accessible from the > candidate slaves. > > > CODE-CHANGES > ============= > Jenkins Version > ------------------------- > The changes were done to org.jenkins-ci.main 1.479-SNAPSHOT and > org.jenins-ci 1.25: > > <parent> > <groupId>org.jenkins-ci</groupId> > <artifactId>jenkins</artifactId> > <version>1.25</version> > </parent> > > <groupId>org.jenkins-ci.main</groupId> > <artifactId>pom</artifactId> > <version>1.479-SNAPSHOT</version> > <packaging>pom</packaging> > > AFFECTED FILES > ----------------------------- > FILE: jenkins-core/src/main/java/hudson/model/AbstractProject.java > DESCRIPTION: Added a new Boolean for the checkbox called > CustomWorkspaceRoot. > > PATCH: > 249a250 > > protected volatile boolean customWorkspaceRoot = false; > 1770a1772 > > customWorkspaceRoot = > req.getParameter("customWorkspace.directoryRoot")!=null; > 2125a2128,2131 > > public Boolean getCustomWorkspaceRoot() { > > return this.customWorkspaceRoot; > > } > > > 2142a2149,2150 > > if ( this.customWorkspaceRoot ) > > this.customWorkspace = this.customWorkspace + "/" + > this.name + "_TEST"; > 2146c2154,2157 > < > --- > > public void setCustomWorkspaceRoot(Boolean c) throws IOException { > > this.customWorkspaceRoot= c; > > save(); > > } > > > ---------------------------------------------------------------------- > > FILE: jenkins-core/src/main/java/hudson/model/AbstractBuild.java > DESCRIPTION: Modified decideWorkspace() to allocate the given > CustomWorkspace in the same way as the "Remote FS root" would be allocated > if the customWorkspaceRoot is enabled. > > PATCH: > 460a461,464 > > if ( getProject().getCustomWorkspaceRoot()) { > > FilePath fp = > n.getRootPath().child(getEnvironment(listener).expand(customWorkspace)); > > return wsl.allocate(fp, getBuild()); > > } else { > 463a468,471 > > } else { > > FilePath fp = > n.getWorkspaceFor((TopLevelItem)getProject()); > > return wsl.allocate(fp, getBuild()); > > } > 465c473 > < return > wsl.allocate(n.getWorkspaceFor((TopLevelItem)getProject()), getBuild()); > --- > > //return > wsl.allocate(n.getWorkspaceFor((TopLevelItem)getProject()), getBuild()); > > ---------------------------------------------------------------------- > FILE: > jenkins-core/src/main/resources/lib/hudson/project/config-customWorkspace.jelly > DESCRIPTION: Added the checkbox that maps to the new customWorkspaceRoot > variable in AbstractProject.java and used in AbstractBuild.java > > PATCH: > 31a32,34 > > <f:entry title="${%DirectoryRoot}"> > > <f:checkbox name="customWorkspace.directoryRoot" > field="customWorkspaceRoot" /> > > </f:entry> > >
