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]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Thursday, September 20, 2012 2:28 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[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>
