Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-18705

Team Concert Plugin is failing in a multi-configuration project

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • teamconcert-plugin
    • None

      I have a multi-configuration project that is configured to run a job with different JDK versions that is configured as shown below:
      ---------------------------------------------------------

      Source Code Management
      Rational Team Concert (RTC)
      RTC repository connection (julianpayne@fr.ibm.com@https://rtcdemeter.francelab.fr.ibm.com:9443/jazz)

      Just accept and fetch from a build workspace
      Build workspace

      Configuration Matrix
      JDK
      IBM-JDK-7 Oracle-JDK-7 IBM-JDK-6

      The problem seems to come from the fact that the "top-level" build:
      -------------------------------------------------------------------

      Started by user julianpayne@fr.ibm.com
      Building on master in workspace /data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace
      RTC : checkout...
      RTC Checkout : Source control setup
      RTC Checkout : Accepting changes into workspace "JenkinsRunAsfTests10" ...
      RTC Checkout : Fetching files to fetch destination "/data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace" ...
      RTC Checkout : Fetching Completed
      Triggering IBM-JDK-7
      Triggering Oracle-JDK-7
      IBM-JDK-7 completed with result FAILURE
      Oracle-JDK-7 completed with result FAILURE
      Finished: FAILURE

      Then the individual builds try to do a checkout in their private workspace:
      ---------------------------------------------------------------------------

      Started by upstream project "RunAsfTests10" build number 2
      originally caused by:
      Started by user julianpayne@fr.ibm.com
      Building on master in workspace /data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace/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/jdk/IBM-JDK-7 because one already exists at /data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace
      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/jdk/IBM-JDK-7 because one already exists at /data/demeter/dev/jenkins-build/jobs/RunAsfTests10/workspace 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)

          [JENKINS-18705] Team Concert Plugin is failing in a multi-configuration project

          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.

          Heather Fraser-Dube added a comment - 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.

          Julian Payne added a comment -

          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?

          Julian Payne added a comment - 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?

          Julian Payne added a comment -

          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)?

          Julian Payne added a comment - 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.

          Heather Fraser-Dube added a comment - Actually the 2 directories are nested. The paths that are given for "Directory" and the "Directory for sub builds" must be absolute.

          I see a similar problem. I tried the workaround you suggested above but it won't work for a master slave setup (workspaces are in different locations). Therefore, I cannot hard-code the directories and I found that ${WORKSPACE} is not substituted at all.

          Any hints?

          Florian Rosenberg added a comment - I see a similar problem. I tried the workaround you suggested above but it won't work for a master slave setup (workspaces are in different locations). Therefore, I cannot hard-code the directories and I found that ${WORKSPACE} is not substituted at all. Any hints?

          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.

          Heather Fraser-Dube added a comment - 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.

          Heather Fraser-Dube added a comment - 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

          Heather Fraser-Dube added a comment - 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?

          Heather Fraser-Dube added a comment - 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}

          Heather Fraser-Dube added a comment - 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}

            Unassigned Unassigned
            julianpayne Julian Payne
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: