RTC SCM does not allow sandboxes to be nested within one another.

The error indicates that the RTC repository workspace has been loaded in one directory (workspace) and the second build is trying to create a sandbox (workspace/jdk/IBM-JDK-7) within the original sandbox when doing the load. The directories are:
/data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace
/data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace/jdk/IBM-JDK-7

I am not sure if it is really your intent to have them nested, but its not supported.

One option is in the Jenkins Job(s) under Advanced Project Options, check off "Use custom workspace" and specify a directory that will be a sibling of the other builds.

Another option is to create a Build definition and on the Jazz Source Control tab specify the Load directory (right now its a relative path from the Jenkins Job's workspace). You might need a couple of build definitions, one for each job.

I will look at your suggestions - thanks.

However it seems to me that the problem is that the RTC plugin is doing a checkout in the root project and it is this checkout that is causing the problem? If you look at the trace that I sent you will see that the "configured sub-projects" are checking out the code correctly in a sub-project (but using the same workspace because that is how multi-configuration projects are defined in Jenkins). The nesting comes from the initial checkout in the root project by the RTC plugin which is superflous as we are not going to do any builds in the root project?

Can you confirm that the multi-configuration project does work with the RTC plugin and if yes could you provide me with an example so that I can see what I am doing wrong in my configuration?

Thanks again for your help.

I see your point. I have been looking into this more. I am not sure how you configure a matrix build not to load in the root project, just in the sub project. Can you help me understand your matrix build configuration (so I can sort of replicate)?

What I am trying to do is fairly simple. I have a Jenkins job that builds a maven project using the maven goals "clean deploy". As part of these goals the unit tests are being run and reported by Jenkins (and/or RTC now that you have added the RTC build support). What I wanted to do with the multi-configuration project is run the maven project with the goals "clean test" but with different JDK's as we have seen some problems moving between JDK6 and JDK 7. Hence I created several JDK's in my Jenkins configuration and then I created a multi-configuration project and selected my different JDK's.

I've replicated the problem and my suggestion regarding the build definition is not likely to work. I have though figured out how to configure the project so that it will load into non-nested directories.

In the section "Advanced Project Options" click the advanced settings button

Check the box "Use custom workspace" it will expand a section to supply workspace paths for the main build and the sub-builds.

In the "Directory" textbox, put an absolute path and a directory in which to load for the main build.
ie. /data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace/mainJob

In the "Directory for sub-builds" textbox, put the same absolute path minus the directory for the main build followed by /${JOB_NAME}
i.e. /data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace/${JOB_NAME}

The JOB_NAME is a variable populated by Jenkins, there may be nicer variables, but I haven't found them. The other key point is to use an absolute path for each directory. The use of the variable will result in each of the sub jobs having their own directory.

This looks like it will work - it is a bit cumbersome though and will need to be done by hand for any multi-configuration project that uses RTC. Are you planning a solution in the RTC plugin to prevent a checkout in the main job or some other solution that does not require this manual fix?

I tried this and in fact it does not seem to work?

Building on master in workspace /data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace/mainJob/jobs/RunAsfTests10/workspace/RunAsfTests10/jdk=IBM-JDK-7
RTC : checkout...
RTC Checkout : Source control setup
RTC Checkout : Accepting changes into workspace "JenkinsRunAsfTests10" ...
FATAL: RTC : checkout failure: Cannot create sandbox at /data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace/mainJob/jobs/RunAsfTests10/workspace/RunAsfTests10/jdk=IBM-JDK-7 because one already exists at /data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace/mainJob
com.ibm.team.filesystem.client.FileSystemStatusException: Status ERROR: com.ibm.team.filesystem.client code=0 Cannot create sandbox at /data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace/mainJob/jobs/RunAsfTests10/workspace/RunAsfTests10/jdk=IBM-JDK-7 because one already exists at /data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace/mainJob null
at com.ibm.team.filesystem.client.internal.copyfileareas.CopyFileAreaManager.createCopyFileArea(CopyFileAreaManager.java:309)
at com.ibm.team.filesystem.client.internal.copyfileareas.CopyFileAreaManager.createCopyFileArea(CopyFileAreaManager.java:1)
at com.ibm.team.filesystem.client.internal.SharingManager.register(SharingManager.java:1002)
at com.ibm.team.build.internal.hjplugin.rtc.RepositoryConnection.checkout(RepositoryConnection.java:363)
at com.ibm.team.build.internal.hjplugin.rtc.RTCFacade.checkout(RTCFacade.java:387)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at com.ibm.team.build.internal.hjplugin.RTCFacadeFactory$RTCFacadeWrapper.invoke(RTCFacadeFactory.java:92)
at com.ibm.team.build.internal.hjplugin.RTCCheckoutTask.invoke(RTCCheckoutTask.java:107)
at com.ibm.team.build.internal.hjplugin.RTCCheckoutTask.invoke(RTCCheckoutTask.java:31)
at hudson.FilePath.act(FilePath.java:906)

As you can see the 2 checkout directories are adjacent and not nested but it still complains about the sandbox (maybe because they are both using the same repository workspace)?

Actually the 2 directories are nested. The paths that are given for "Directory" and the "Directory for sub builds" must be absolute.

Unfortunately, no I haven't found any other workarounds. Environment variables for the build itself did not seem to be available to Jenkins in the deciding the workspace path. Only thing I can think of is defining environment variables in the environment that Jenkins runs in and seeing if they are substituted in the calculation of the workspace path. If that worked, setting it in the slave environment and the master environment might be an option.

I will experiment with this tomorrow if possible.

I have opened a defect in RTC to describe some of the I've seen issues with multi-configuration projects seen so far. 274912: Jenkins plugin and Matrix builds

Florian, Do you need to have the source checked out/loaded in the main build as well as the children builds?

Florian a workaround is to use environment variables :

• Go to Jenkins > Manage Jenkins > Configure
• In the Global properties section define an environment variable that references the path for the root of your workspace. It will need to be an absolute path.
  example: MYMATRIXWS C:\MyMatrix\jobs

• Go to Jenkins > Manage Jenkins > Manage Nodes choose your slave node choose Configure
• In the Node properties section define the same environment variable again, but reference the path for the root of your workspace on the node. It will need to be an absolute path.
  example: MYMATRIXWS C:\MySlaveMatrix\jobs

• Go to Jenkins > Jobs choose your job choose Configure
• In the section "Advanced Project Options" click the advanced settings button
• Check the box "Use custom workspace" it will expand a section to supply workspace paths for the main build and the sub-builds.

• In the "Directory" textbox, put in your environment variable followed by a directory in which to load for the main build.
  example: ${MYMATRIXWS}/workspace/mainJob

• In the "Directory for sub-builds" textbox, put in your environment variable followed any subdirectory minus the directory for the main build, followed by /${JOB_NAME}
  example: ${MYMATRIXWS}/workspace/${JOB_NAME}