The directory structure described above is still true when using Jenkins 1.403.
But this issue is an improvement and not a bug because it has no impact on the builds.
Downgrading to minor, because the reporter has not given any important reason for this improvement to be major.

Why this directory structure should be changed and why is it important?

How this could be an improvement?

I have slave for SVN merging purposes that works on Hudson workspaces. Recently I have separated main builds in two groups - for master and slave (project are tie to specific node). Now should svn merging job guess where to find workspace?

I believe this should be changed just to keep consistency alone, but if you want to automatically run a tool which needs the workspace directory as an arguement, this might cause problems.

See JENKINS-8446.

Manage Jenkins->Configure System -> Advanced button under "Home Directory", You can see "Workspace Root Directory" and "Build Record Root Directory".

Did some one find a workaround to this issue?
I am trying to run several parallel jobs on a slave machine and the fact that the folder structure is reversed is problematic in this case at least - it's a blocker for me (unless there is a way to chance this setting - not sure if that what sogabe was trying to communicate).

Here the example in my case:

the folder structure on the slave looks like:
C:\hudson
C:\hudson\workspace\
C:\hudson\workspace\builds
C:\hudson\workspace\job1
C:\hudson\workspace\job2
C:\hudson\workspace\jobn

So one problem I see here is the builds folder seems to be shared between the jobs! At least it looks like that. And any folder that normally is generated in the workspace folder of the job (even temp folders) will be generated on top of the job folder. I hope there is a way to work around this. Please advise~

moe

Is anybody working on this?

I believe that builds folder should not be shared between builds, and it should be consider a bug, as master's folder structure is not been replicated.

Echoing the call of HELP. Is anybody working on this. The shared builds folder between the jobs is problematic !

I figured I'd chime in with a use case where this presents a problem. We use git repositories and for each repository we have three mainline permanent branches that we set up builds for. We use the git clone reference feature to "share" common code: so that the "development" branch pulls the full clone and fetch since it is the most commonly updated; to speed up clones and take up significantly less disk space the two less frequently updated branches for each repo point at the "development" workspace as the clone reference (and wipe their workspace every build to clone against the reference again).

But setting up the jobs to point to the "development" branch job's workspace directory is difficult because the structures are different between master and slave. I ultimately defined custom ENV variables on the master and overrode them on the slaves: $JOBS_DIR and $WORKSPACE_SUFFIX, so that the reference path could be defined as something like: "$JOBS_DIR/job-name-development$WORKSPACE_SUFFIX". Otherwise, I was trying to use $WORKSPACE and relative paths, and I could only choose the build it correctly for my master node or my slave nodes, but not both.

I had some trouble with the directory structure too, as there are jobs that copy their build results to another jobs workspace. This is done to be able to reuse the results for deployment even if another build is currently running.
I know there may be other and better solutions but one is not always able to change all legacy scripts at once, so that caused a lot of unnessesary problems.

I think the slave should mirror the master behavior as much as possible and so use the structure configured in the jenkins global configuration that sogabe pointed to.

Simple Problem Case:
build script used by a job run requires full path to workspace. Simple enough to build as:
${Jenkins_Root}/jobs/${Job_Name}/workspace

Now add a slave to do builds, all builds fail because path is no longer correct.

That this has been labeled Minor because it "...has no impact on the builds." is incorrect, it most assuredly has impact on builds.