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

Cannot use Jenkins Node properties as load directory for Team Concert plugin

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • teamconcert-plugin
    • Jenkins 1.656 Team-concert 1.2.0.1

      There is no way to specify a predefined Node property environment variable as the Load directory for a build job using RTC source code management.

      So if you have multiple build nodes, you can't defined lets say: SRC_BASE uniquely for each node and then consume that Node property environment variable in a build job, so that the build job could execute on any node available.

      Some details; we have two linux hosts and two windows hosts setup as a build farm. These four hosts are configured as individual nodes in Jenkins. We want to configure our build jobs so they can run on any node. But there is no way to tell team concert to load to a location on the host that is platform independent. So if node1 was configured with a node property environment variable SRC_BASE=/opt/rtc/ssd and node2 was configured with a node property environment variable SRC_BASE=c:/common/rtc. Then I should be able to configure my build job to use the load directory ${SRC_BASE}/productname.

      This currently does not work as it treats ${SRC_BASE} as a string and appends that to the default load directory location.

          [JENKINS-38357] Cannot use Jenkins Node properties as load directory for Team Concert plugin

          Rob Leach added a comment -

          Sorry, one other point to bring up I thought about last night. The example I provided is probably not the best example, but it underscores the point. This is not limited to just the location of the load source directory. It's applicable for any Node property environment variable that might be unique to a Node, and that needs to be consumed by a build job.

          Other examples could be the location of required build libraries (such as WebSphere or Java) which might be located in different directories on each node.

          A property file can help with this issue, but being able to manage that in the build job can be quicker, and not require the overhead of updating property files in source control etc.

          Rob Leach added a comment - Sorry, one other point to bring up I thought about last night. The example I provided is probably not the best example, but it underscores the point. This is not limited to just the location of the load source directory. It's applicable for any Node property environment variable that might be unique to a Node, and that needs to be consumed by a build job. Other examples could be the location of required build libraries (such as WebSphere or Java) which might be located in different directories on each node. A property file can help with this issue, but being able to manage that in the build job can be quicker, and not require the overhead of updating property files in source control etc.

          robleach Can you please clarify if the problem with using Node properties Environment variables in the Load Directory field, is happening with a free style job or a pipeline job?

          Sridevi Sangaiah added a comment - robleach Can you please clarify if the problem with using Node properties Environment variables in the Load Directory field, is happening with a free style job or a pipeline job?

          Rob Leach added a comment -

          A free style job.

          Rob Leach added a comment - A free style job.

            ssangaiah Sridevi Sangaiah
            robleach Rob Leach
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: