The @N notation I was referring to was just the style of path you cited in your first scenario:
job1 - /Nodes/path/job job2 - /Nodes/path/job@2 job3 - /Nodes/path/job@3 The @2 and @3 were added by Jenkins because you configured concurrent builds. I think you're actually describing two features: 1. Make sure that jobs with custom workspaces work correctly when configured to run concurrent builds. This is what I thought you were after, and so I felt that this should just work, without requiring additional user configuration. 2. Allow the workspace a job uses to be passed as a parameter from one job to the next. -- Dean From: Marek Gimza <marekgi...@gmail.com<mailto:marekgi...@gmail.com>> Reply-To: "jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>" <jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>> Date: Saturday, September 22, 2012 8:01 AM To: "jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>" <jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>> Subject: Re: Checkbox to allow the Custom Workspace be shared among different slaves. 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 <d...@shutterfly.com<mailto:d...@shutterfly.com>> 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 <marekgi...@gmail.com<mailto:marekgi...@gmail.com>> Reply-To: "jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>" <jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>> Date: Thursday, September 20, 2012 2:28 PM To: "jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>" <jenkinsci-dev@googlegroups.com<mailto:jenkinsci-dev@googlegroups.com>> 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<http://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>
