Child pages
  • Team Concert Plugin
Skip to end of metadata
Go to start of metadata

View Team Concert Plugin on the plugin site for more information.

Integrates Jenkins with Rational Team Concert source control and build using the richer features of the build toolkit instead of the command line.

With the build toolkit this plugin adds traceability links from a Jenkins build to an RTC build result, workspace and snapshot.  It also publishes links to work items, change sets and file contents captured in the snapshot.  It leverages the current RTC features and workflows that users are already familiar with such as, emails, toaster popups, reporting, dashboards, etc.

Documentation

Rational Team Concert Help Topics

  1. Rational Team Concert Build Overview
  2. Installing the Build System Toolkit
  3. Creating encrypted password files
  4. Hudson/Jenkins build engine type
  5. Dedicated build workspaces

Requirements

This plugin requires Rational Team Concert Build Toolkit version 4.0.7 or newer. Older versions of the plugin supports build toolkit versions starting from 3.0.1.5. See the Installing the Build System Toolkit help topic to learn how to install the build toolkit.

A valid build toolkit is required on master and slave for all build configurations.

 

Some features depend on specific Rational Team Concert build toolkit  or server versions. See below.
  • Stream configuration works only from build toolkit v. 5.0 or higher.
  • Post Build Deliver for Build Definition configuration introduced in Team Concert Plugin v. 1.2.0.3 depends on Rational Team Concert server version 6.0.4 or higher.
  • Support for Load Rules in build definition has some requirements on the version of RTC client used to create the build definition. See Load Rules Support section for more details.
  • If you will be fetching workspaces that contain symbolic links, there is some additional symbolic link setup required. See Symbolic Link Support section for more details.
  • Team Concert Plugin v 1.1.2 and later depends on the Jenkins Credentials plugin version 1.10 or later.

Jenkins Configuration

  1. Navigate to the Jenkins Global Tool configure page (Jenkins > Manage Jenkins >  Global Tool Configuration) and find the "RTC Build toolkit" section.  This section is used to define one or more build toolkits available to the plugin.If you are using Jenkins 1.x, this will be under (Jenkins -> Manage Jenkins -> Configure System)
  2. Click the "RTC Build toolkit installations..." button and add a new build toolkit.
    • See the Installing the Build System Toolkit help topic to learn how to install the build toolkit.
    • There can be multiple RTC build toolkits associated with one jenkins instance.
  3. Click the "Apply" button to apply the changes.
  4. Navigate to the Jenkins Global Configuration page (Manage Jenkins -> Configure System).
  5. Find the "Rational Team Concert (RTC)" section. This section is used to define global connection settings that will be the defaults for any jobs created with the plugin. If connection settings will be set on each job, then skip this section. 
    • Select a build toolkit
  6. Credentials are managed by the Credentials plugin. The Team Concert plugin supports username and password type credentials. Credentials can be defined within a domain or a folder (if you are using the folder's plugin).
  7. Choose the credentials to use when logging into RTC for polling and building.
    • If you are using the 1.0.12 (or earlier) version of the Team Concert plugin, instead of credentials, you will need to supply a userId and password or password file.
  8. Click the "Test connection" button to verify the repository connection details.
  9. Click the "Save" button to save the settings and return to the Jenkins main page.

Job Configuration

  1. Create a new free-style software project and find the "Source Code Management" section.
  2. Select "Rational Team Concert (RTC)".
  3. If global connection settings were not configured above or do not apply to this job, then check the "Override global RTC repository connection" check box and enter the connection settings here.
  4. Click the "Test connection" button to verify the repository connection details.
  5. Prior to 1.2.0.0 a job can be configured with RTC SCM using either a build definition or a build workspace. In 1.2.0.0 there is support to configure RTC SCM with a build stream or build snapshot also.
  6. To benefit most from the integration between this plugin and RTC Build, select "Build Definition" from the Build Configuration dropdown and enter a build definition ID. See the Hudson/Jenkins build engine type help topic to learn how to create a Jenkins build definition.
    • Notice the "Build Configuration" dropdown which replaces the radio buttons for build definition and build workspace.
    • Click the "Validate" button to verify the RTC build definition exists.
    • There is a bit of a catch-22 here.  A Jenkins job requires a Hudson/Jenkins build definition and a Hudson/Jenkins build definition requires a Jenkins job.  RTC actually won't let you save the build definition without a job selected.  However, Jenkins will let you save a job without a build definition.  So it is important to configure your build definition and job this way.
      1. In Jenkins, create the job first using RTC for source control, but with no build definition
      2. In RTC, create a build engine if you haven't already
      3. In RTC, create a build definition using the build engine and set the job
      4. Lastly, in Jenkins, revisit the job and set the build definition
  7. To load the jenkins build workspace using a RTC repository workspace, select "Build Workspace" from the Build Configuration dropdown. See the Dedicated build workspaces help topic to learn how to create a build workspace.
    • Click the "Validate" button to verify the RTC build workspace exists.
  8. To load the jenkins build workspace using a snapshot, select "Build Snapshot" from the Build Configuration dropdown. This configuration is mainly intended to be used in builds that capture the current state of the RTC SCM workspace/stream in a snapshot and start downstream builds that would populate the jenkins build workspace from the snapshot created and passed from the upstream builds.
    • To start a downstream snapshot build Parameterized Trigger plugin is required.
      • Consider a parent job that is configured to load from a RTC repository workspace. When the build runs, Team Concert Jenkins plugin creates a snapshot on the build workspace. The snapshot uuid is available as the build environment property team_scm_snapshotUUID.
      • Add a post build action to trigger parametrized build on other projects.
    • Configure a downstream snapshot build
      • Create a new job and with a string parameter named "rtcBuildSnapshot"
      • Configure Rational Team Concert under Source Control options to build from a snapshot.
    • Now when an upstream build is started and once it is done it will trigger the downstream build with the UUID of the snapshot created on the workspace.
    • Note that the change log is not generated and polling is not supported for load from snapshot as this as an immutable configuration.
  9. To load the jenkins build workspace using a stream, select "Build Stream" from the Build Configuration dropdown.
    • Click the "Validate" button to verify the build stream exists.
    • This configuration supports building from the current state of the specified stream.
    • Subsequent builds capture the changes made to the stream since the previous build.
    • In this configuration change log can be chosen to be generated by comparing the current build with the previous successful build. By default this option is unchecked.
    • For this configuration the RTC user configured globally or for this job needs to have permission to attach snapshots to a stream
  10. In 1.2.0.0 some of the load and accept options that were previously configurable only in RTC build definitions, can be specified in the jenkins job configuration. The accept and load options are available for build configurations other than load using a build definition.
    • The directory on the build machine under which the repository files will be loaded can be specified.
    • Contents of the load directory can be deleted before reloading
    • Load Policy field, added in 1.2.0.4, can be used to configure the components to load. You can either specify the components to load or choose to use a remote load rule file or dynamic load rules, to determine which components to load.
      • Specify which components to load
        • When specifying components to load you can choose to create folders for components, in which case the load directory would have folders for components at the top level and each of these folders will have the files/folders for that component.
        • You can also choose to exclude some components.
      • Load components by using a load rule file
      • Load using dynamic load rules
    • For more details on load rules support and how to configure dynamic load rules, see the Load Rules Support section.
    • When loading the jenkins build workspace from a RTC repository workspace, there is an option to configure whether to accept latest changes before loading. By default, this option is selected.
  11. Find the "Build Triggers" section.
  12. Check the "Poll SCM" check box to poll for incoming changes to the build workspace.
  13. Enter a schedule.  Click the help button beside the "Schedule" field to get help with the syntax.
  14. Click the "Save" button to save the settings and return to the job page.

Configuring Jenkins job for Post Build Deliver (Build Definition configuration only)

  1. In 1.2.0.3, Post Build Deliver is supported for Build Definition configuration. The RTC server version should be 6.0.4 or higher.
  2. Configure the RTC Build Definition with Post Build Deliver configuration.
  3. In the Jenkins Freestyle job configuration, add the "RTC Post Build Deliver" post build action. Select "Fail on Error", if you want  the build to fail if post build deliver fails.
  4. Optional : If a Pipeline job is being used, then add the following snippet before the end of the script to perform post build deliver as the last step of the build.
  5. PB deliver snippet
    step([$class: 'RTCPostBuildDeliverPublisher', failOnError: true])

Master/Slave Configuration

Master and slave configurations are supported by this plugin.  See the Jenkins documentation on distributed builds for more information.  The RTC build toolkit home path is required for the master to be able to test connections and build artifacts.

Note: If a password file is being used to authenticate with the RTC server for a particular job, it is unnecessary to copy that file to each of the slaves.  The master extracts the password from the password file and passes it to each slave required.

  1. Navigate to the Jenkins /computer/? page (Jenkins > Manage Jenkins > Manage Nodes) and click the "New Node" link.
  2. Enter a name and create a "Node name", select the "Dumb Slave" radio button and click the "OK" button.
  3. In the node configuration page, find the "Node Properties" section and check the "Tool Locations" check box.
  4. From the list of tool locations, select the build toolkit you want to define for the node, and set the value in the "Home" field.
    •  

Build toolkits can also be installed automatically on slaves.  And labels can be used to match build toolkits to slaves.  However, a home path is still required so the master can test connections and build artifacts.

  •  

RTC Log

This section can be used to capture the log when debugging a problem with the plugin.

  1. Navigate to the Jenkins /log page (Jenkins > Manage Jenkins > System Log) and click the "Add new log recorder" button.
  2. Name it something like "RTC Log" and click the "Add" button to add a logger.
  3. Enter a logger of "com.ibm.team.build" and set the log level to "FINER".
  4. Click the "Save" button.
  5. Return to this log if a problem is ever experienced using this plugin.  The log will help to identify the problem.

Logging on Slaves

  • On the Slave while messages are logged at level FINER, the logs never come back.
  • There is support for a debug flag which will result in the debug output going into a build's console log
  • The environment variable "com.ibm.team.build.debug" with the value "true" will activate the debug logging on a slave.
    • To configure on a single Slave
      1. Jenkins > Manage Jenkins > Manage nodes
      2. Hover over the link of the node to configure. Choose Configure from the popup context menu
      3. In the Node properties section, select and check the Environment variables checkbox
      4. Click the Add button beside the List of key value pairs.
      5. Supply "com.ibm.team.build.debug" as the name and "true" as the value
      6. Click the Save button.
    • Alternately to configure on the Master and all Slaves
      1. Jenkins > Manage Jenkins > Configure System
      2. In the Global Properties section, select and check the Environment variables checkbox
      3. Click the Add button beside the List of key value pairs.
      4. Supply "com.ibm.team.build.debug" as the name and "true" as the value
      5. Click the Save button.
  • The debug flag currently only logs information relating to the class loader setup. The rest of the logic should not be affected by running on a Master or a Slave so if you need those logs, consider running on the Master to get the detailed logs.

RTC related Environment Variables available to the Build

The following environment variables are available to the build after Rational Team Concert source control step is completed.

property

description

team_scm_changesAccepted

The number of changes accepted or discared during the build.

team_scm_snapshotUUID

UUID of the snapshot created after accepting changes. Not set if no snapshot was created.

team_scm_workspaceUUID

The UUID of the Repository workspace used in the build. Only set if the build is using a build definition.

RTCBuildResultUUID

UUID of the build result. Only set if the build is using a build definition

requestUUID

UUID of the build request. Only set if the build is using a build definition.

buildDefinitionId

UUID of the build definition being used by the build. Only set if the build is using a build definition.

repositoryAddress

Address of the RTC repository.

buildEngineId

Name of the build engine associated with the build request/result (if there is a build result). An RTC build engine is not actually running, but some ant tasks need the engine id.

buildEngineHostName

Host name of the Jenkins master or slave that the build is running on.

buildRequesterUserId

User id of the RTC user that requested the build be started. Only set if the build is using a build definition

personalBuild

True if the build is a personal build (requested from RTC), otherwise, not set

rtcTempRepoWorkspaceName

The name of the temporary Repository Workspace created during a build using Stream configuration

rtcTempRepoWorkspaceUUID

The UUID of the temporary Repository Workspace created during a build using Stream configuration

Accessing RTC Environment Variables in a Pipeline Job

Note 1:

With the fix from Issue 26100, checkout step now returns a map that is expected to be populated by the SCM invoked in that step. Team Concert Plugin needs to adopt some changes and that is tracked through Enhancement 446242. Once the adoption is complete,  variables that were earlier contributed to the environment will now be available in the map. Till the enhancement is resolved, you can obtain the snapshotUUID from env object. If you are using Jenkins 2.73.3 and above, read the note below on how to access RTC Environment variables.

Note 2:

With workflow-cps 2.40, the env object is repopulated. See JENKINS-42499 and this Jenkins developers forum post.

Therefore, the issue reported in Defect 370979 - Environment variables for snapshot, build result UUID are null if env object is accessed before running teamconcert checkout step, in a pipeline script  and the issue reported in this jazz.net forum post are not seen anymore. After every checkout, you can save each snapshot UUID into a separate variable as follows

echo "${env.BUILD_NUMBER}"

 node {
   checkout([$class: 'RTCScm'...])
   // At this point, env contains RTC related environment variables from the first checkout
   def snapshotUUID1 = "${env.team_scm_snapshotUUID}"
   echo "${snapshotUUID1}"

   checkout([$class: 'RTCScm' ....])
   // At this point, env contains RTC related environment variables from the second checkout. The environment variables contributed by the first checkout are overwritten.
   def snapshotUUID2 = "${env.team_scm_snapshotUUID}"
   echo "${snapshotUUID2}"
 }

 

If you are using workflow-cps < 2.40, follow the workaround mentioned below.

Workaround

In a pipeline job the environment variables published by the Team Concert Jenkins plugin is null if the env object is accessed once before the RTC SCM checkout step. For instance, the following script would return the UUID of the snapshot published by the Team Concert plugin.

node('master') {
    // run teamconcert scm step
    echo "${env.team_scm_snapshotUUID}"
 }

But in the script given below the env object is accessed once before running the checkout step and hence accessing the snapshot UUID from the env object returns null

echo "${env.BUILD_NUMBER}"
node('master') {
    // run teamconcert scm step
    echo "${env.team_scm_snapshotUUID}"
 }

Though the Team Concert plugin publishes the environment variables when checkout is invoked, in pipeline scripts the env object once constructed is not refreshed with any of the environment variables, published later. Neither the SCM checkout interface supports returning of any values from the implementation. See https://issues.jenkins-ci.org/browse/JENKINS-26100.

If you run into issues accessing the environment variables published by the Team Concert plugin, the suggested work around is to access the RTCBuildResultAction object that is added to the build by the Team Concert plugin. The following code returns the build properties stored in RTCBuildResultAction object. This can be used in a pipeline script to obtain snapshot UUID.

def action = currentBuild.build().getAction(com.ibm.team.build.internal.hjplugin.RTCBuildResultAction.class)
def buildProps = action.getBuildProperties()
println(buildProps['team_scm_snapshotUUID'])

Please note that if you invoke RTC SCM multiple times, then there will be that many RTCBuildResultActions in the build. Therefore, currentBuild.build().getActions(com.ibm.team.build.internal.hjplugin.RTCBuildResultAction.class) should be used. The action added by the last invocation of RTC SCM should be available at the end of the list. For instance, if there are two RTCScm checkouts, the second RTCBuildResultAction can be accessed as follows.

 

def actions = currentBuild.build().getActions(com.ibm.team.build.internal.hjplugin.RTCBuildResultAction.class)
def buildProps = actions.get(1).getBuildProperties()
println(buildProps['team_scm_snapshotUUID'])

 

Wrapping the code in a Global Shared Library

The above code cannot be directly used in a pipeline script. You can wrap this code inside a method and add it to a Global Shared Library. You can then call the method from your pipeline script.

If you are already using a Global Shared Library in your environment, add the following code in a file called rtcutils.groovy and place the file under the vars directory,

 def getSnapshotUUID(actionNum) { // The n'th RTCBuildResultAction.
    def actions = currentBuild.build().getActions(com.ibm.team.build.internal.hjplugin.RTCBuildResultAction.class)
    if (actions != null && actions.size() > 0 && actionNum > 0 && actionNum <= actions.size()) {
        def buildProps = actions.get(actionNum-1).getBuildProperties()
        return (buildProps['team_scm_snapshotUUID'])
    } 
    return null
}

Then, in your pipeline script, you can write the following to get the snapshotUUID of the checkout step.

@Library('your-shared-library')_

node {
   checkout([$class: 'RTCScm'...])

   def snapshotUUID = rtcutils.getSnapshotUUID(2) // pass 2 if the shared library is fetched from RTC, otherwise pass 1
   echo "${snapshotUUID}"
}

 

If you don't have Global Shared Library in your environment, consult https://jenkins.io/doc/book/pipeline/shared-libraries on how to create and access a shared library in your pipeline script. Note that if you use RTC for hosting the Global Shared Library, then there will be a RTCBuildResultAction added to the build at the point where the library is brought into the pipeline script.

Symbolic Link support

RTC support for symbolic links requires one or two additional libraries (.dll/.so files).

  • RTC file system natives
  • Eclipse file system natives

The reason is Java 6 and earlier doesn't have support for creating/looking at properties of symbolic links. Java 7 has symbolic link support that works on linux, but on Windows there are some limitations when creating links (if the target has not yet been created the type is defaulted to file which is not good if its a directory). If you are running Linux and can use Java 7 you only need the Eclipse natives. Otherwise, you will need both the RTC and Eclipse natives.

In the Build engine directory (<your RTC build install directory>\buildengine\eclipse\plugins), look for (or equivalent jars for your platform/release).

  • com.ibm.team.filesystem.client_3.1.600.v20130415_0257.jar (RTC file system natives)
  • org.eclipse.core.filesystem.win32.x86_1.1.201.R36x_v20100727-0745.jar (Eclipse file system natives)

From the com.ibm.team.filesystem.client jar you want to extract winfsnatives.dll (libfsnatives.so on linux). Take all the .dll/.so files from the org.eclipse.core.filesystem jar. Place them directly in a directory (eg. c:\natives\winfsnatives.dll).

When you start Jenkins, we need to tell java about the directory so that it can load the libraries from it. To this, you can add the directory to the search path.
Change the PATH variable on Windows or the LD_LIBRARY_PATH variable on linux prior to starting Jenkins. Alternatively, you can also specify it when starting Java through the -Djava.library.path setting.
eg. java -Djava.library.path="c:\natives;%Path%" -jar jenkins-1.509.1.war

If you are running on Windows, you need to be sure that you have permission to create symbolic links. The Symbolic links article in the jazz.net library describes how.

Note: If you are running your jenkins builds on slaves and the symbolic links fail to load, then the native libraries should be included in the JVM library path of slaves too.

Load Rules Support

  • When a jenkins build is configured with an RTC build definition, the component load rules specified in the RTC build definition, if any, will be applied when loading the jenkins build workspace. Component load rules in builds describes how to specify load rules in a build definition.
  • When a jenkins build is configured with an RTC repository workspace, stream, or snapshot load rules can be specified by setting the load policy field to "Load components by using a load rule file".
  • The load policy field for RTC build definition can be set only using the 6.0.5 RTC client.
  • Component load rules can also be specified through dynamic load rules extension. For more details refer DynamicLoadRulesJenkinsPlugin. Dynamic load rules feature is supported across all build configurations - build definition, repository workspace, stream, and snapshot.
  • In build definition configuration, when load rules are configured in the build definition and dynamic load rules are also provided, dynamic load rules take precedence over the component load rules.
  • Note that the till 1.2.0.4 the behavior of load rules in Jenkins builds, when using the component load rules specified in RTC build definition or the load rules generated by the dynamic load rules extension, is different from how eclipse client enforces the load rules. Say, you have a load rules file that loads some but not all of the components in a workspace. This load rules file when used to load a workspace in the eclipse client, will result in loading of only those components specified in the load rules file. When the same load rules file is configured in an RTC build definition, all components from the workspace, including those not specified in the load rules file, are loaded; those components for which load rules are specified are loaded according to the specified load rules, all the other components are loaded as is. The Components to exclude option, in the RTC build definition can be used to restrict which components are loaded during the build - for more details refer Creating RTC build definitions.
  • From 1.2.0.4 the behavior of load rules in Jenkins builds is at par with RTC SCM. So, only those components for which load rules are specified will be loaded, according to those rules; all the other components for which load rules are not specified will not be loaded. To maintain backward compatibility in Jenkins builds configured with an RTC build definition, old load rules behavior will be enforced unless the load policy field in the build definition is set to use load rules.

Known limitations:

  1. In the version 1.2.0.0, Stream configuration is not supported in 4.0.7 toolkit due to the following issues
  2. In the version 1.2.0.0, polling is not supported for stream and snapshot build configurations, when "avoid using toolkit on master (experimental)" is checked.
  3. In the version 1.2.0.0 temporary workspaces are created to support loading from a stream and snapshot. Teamconcert plugin deletes the temporary workspaces when the completes. These temporary workspaces could be left behind in case of network issue during the build. The temporary workspaces can be located by searching for workspaces that starts with the prefix "HJP_".
  4. In the version 1.1.9.5, validating the connections when "avoid using toolkit on master (experimental)" is checked is broken. This issue seems to be do with maven dependencies. The issue is tracked in the work item Error shown when validating a connection with avoid using toolkit on master option checked
  5. You may need to recycle Jenkins and slaves when updating the Team Concert plugin to a new version, or when automatically installing a new build toolkit.
  6. Following are knows issues with Workflow support

Known Limitations (with fixes in newer releases of RTC) :

  • Issue with RTC 6.0 build tool kit and load rules. Due to a breaking change in the RTC 6.0, load rules will not work when using RTC 6.0 build tool kit. Fix is available in 6.0 Ifix07 build toolkit (work item 362564). Refer to the work item Load rules is broken with Jenkins plugin and RTC 6.0 build tool kit (361926) for more details. If you are using load rules then its recommended to use the RTC 5.0.2 build tool kit and not RTC 6.0 build tool kit. Note that this recommendation if only or the version of the RTC build tool kit and and not for the RTC server. The RTC server can either be 5.0.2 or 6.0, since RTC supports n-1 compatibility (i.e an older client can connect to a later server) a 5.0.2 version of the build tool kit will work with RTC 6.0 server.
  • Each build request initiated from RTC creates a buildResultUUID parameter in the Jenkins workflow job.
    • This issue is fixed in RTC v6.0.1 or higher and in 6.0 ifix04, 5.0.2 ifix12.
    • For a workaround follow the steps listed below
      • In the workflow job configuration page, delete all but one buildResultUUID parameters.
      • Add the following under the <flow-definition> tag in the workflow job's config.xml
          <actions>
            <hudson.model.ParametersDefinitionProperty>
              <parameterDefinitions>
                <hudson.model.StringParameterDefinition>
                  <name>buildResultUUID</name>
                  <description>The UUID of the build result in RTC. It is supplied by builds initiated through RTC. For builds initiated through Hudson/Jenkins, no value should be supplied.</description>
                  <defaultValue></defaultValue>
                </hudson.model.StringParameterDefinition>
              </parameterDefinitions>
            </hudson.model.ParametersDefinitionProperty>
          </actions>
      • Click Manage Jenkins-> Reload Configuration from Disk. 

Tutorial

  1. jazz.net wiki topic: Integrating with Jazz SCM and Builds from Hudson and Jenkins using the Team Concert Plugin
  2. YouTube video: Team Concert Plugin for Hudson/Jenkins

References

  1. Using the Team Concert plugin in Pipeline jobs - https://jazz.net/wiki/bin/view/Main/JenkinsWorkflowPluginSupport

Releases

1.2.0.4 December 04, 2017

1.2.0.3 Jun 16, 2017

1.2.0.2 Dec 6, 2016

1.2.0.1 Aug 16, 2016

1.2.0.0 April 22, 2016

1.1.9.9 January 25, 2016

1.1.9.8 December 21, 2015

Fix for work item 379521- RTC Jenkins plugin leaving .jazzlock file in the workspace, is not available in 1.1.9.8. The issue has been fixed 1.1.9.9

1.1.9.6 and 1.1.9.7 October 26, 2015

1.1.9.6.1 October 26, 2015

  • Invalid plugin release, do not use

1.1.9.5 September 21, 2015

1.1.9.4 August 04, 2015

1.1.9.3 July 26, 2015

1.1.9.2 June 11, 2015

1.1.9.1 March 26, 2015

  • RTC build plugin for Jenkins repeatedly resets the "Quiet period" work item 350379

1.1.9 October 9, 2014

There is a migration impact for this release. See the Migrations section below.

  • When a Jenkins build is deleted, the corresponding RTC build result(s) (if there are any) are deleted from RTC. The RTC build result will not be deleted it it is flagged as deletion is not allowed. work item 330249
  • Improve support for "Multiple SCMs" plugin. You can now specify multiple RTC SCM configurations referencing different servers (when builds are started from Jenkins). work item 300164
  • Support so RTC's Build Definition editor can warn the user if the Jenkins job doesn't point to that definition work item 276139
  • Thread's context class loader not reset properly + work around for unexpected failure to load LogFactory class work item 322272

1.1.8 July 10, 2014

  • Main Jenkins configuration page was not showing the chosen Build toolkit work item 320832
  • Add warning to console log when build workspace has components not visible to the build user work item 203294
  • When the SCM provider is the "Multiple SCMs" plugin, the detailed changes for a build does not list the change details work item 323307

1.1.2 June 11, 2014

  • Support for Jenkins credentials has been added which introduced a dependency on the Credentials plugin. If a job is already configured to use user ID and password (or password file) , it will continue to run but these fields are read only. Any changes will require credentials going forward.  Using the Credentials plugin offers more flexibility and solves some issues.
    • Multiple credentials can be defined and used in multiple jobs
    • Can use a global user ID and password (or password file) when the RTC URL is overridden issue 21537
    • Improves Security issue 21038 work item 295009
  • Work related to starting a build with an RTC build result has been moved from the Master to the Slave (assuming the job is running on the Slave). Work item 306172
  • When builds are started within RTC, the server will manage the lifecycle of the build result by periodically polling Jenkins to determine if the build is completed. With RTC 5.0, build definitions support the boolean property com.ibm.rational.connector.hudson.queueOnly. When used in conjunction with this release of the plugin, the plugin will terminate the RTC build result when the build completes (just as it does when the build is started in Jenkins). If a lot of builds are started from within RTC, this will be more efficient. Requires RTC version 5.0 or later. Work item 308749
  • New option to use rest service calls to communicate with the RTC Server when performing configuration, polling and build result management (as opposed to the build toolkit). This means if all the jobs have this configured and run on slaves, the toolkit classes will not be loaded on the master. Requires RTC version 5.0 or later.

1.0.12 (and earlier) October 23, 2013

  • This plugin version does not have any Jenkins specific dependencies.
  • To authenticate against an Team Concert server a user id and password is required. The password can be supplied directly or it can be placed in a password file.
  • The RTC build toolkit is used perform build related tasks within Jenkins Master and Slave processes (as opposed to using a command line client). The RTC related tasks include validating the configuration, polling and working with the RTC build result as well as performing the Accept and Checkout phases of the build.
  • Support for a simple build workspace
    • Changes are accepted into the build workspace from the stream(s) referenced by the flow target(s)
    • Snapshot of the workspace is created for a build
    • Change log is created
    • Build workspace is loaded
  • Integrated support for build definitions
    • Traceability links from a Jenkins build to an RTC build result, workspace and snapshot. 
    • Publishes links to work items, change sets and file contents captured in the snapshot. 
    • Build workspace is identified by the Build definition
    • Changes are accepted into the build workspace from the stream(s) referenced by the flow target(s)
    • Snapshot of the workspace is created for a build
    • Additional SCM configuration options available in the build definition
    • RTC Build result is created for a deeper integration with the work items included in the build
    • Builds (including personal builds) can be started from RTC
    • Environment variables defined in the RTC build definition are available in the build environment
  • RTC build environment variables are available in the build environment

    property

    description

    team_scm_changesAccepted

    How many changes were accepted. Not set if there were no changes.

    team_scm_snapshotUUID

    UUID of the snapshot created after accepting changes. Not set if no snapshot was created.

    RTCBuildResultUUID

    UUID of the build result. Only set if the build is using a build definition

    requestUUID

    UUID of the build request. Only set if the build is using a build definition.

    buildDefinitionId

    UUID of the build definition being used by the build. Only set if the build is using a build definition.

    repositoryAddress

    Address of the RTC repository.

    buildEngineId

    Name of the build engine associated with the build request/result (if there is a build result). An RTC build engine is not actually running, but some ant tasks need the engine id.

    buildEngineHostName

    Host name of the Jenkins master or slave that the build is running on.

    buildRequesterUserId

    User id of the RTC user that requested the build be started. Only set if the build is using a build definition

    personalBuild

    True if the build is a personal build (requested from RTC), otherwise, not set

Migrations

1.1.9

  1. The environment variable buildResultUUID is a parameter that is supplied to the Jenkins job when the build started from RTC. It was sometimes also being updated (contributed by this plugin) even if the build was started in Jenkins. In order to better support building multiple projects with the Multiple SCM plugin, the environment variable will not be updated by this plugin. The build result UUID is still available from the RTCBuildResultUUID regardless of where the build was started from.

1.1.2

  1. Jenkins Credentials Plugin is now used for storing the user ID and password. For an existing global configuration and jobs, the user ID and password (or password file) fields will be read-only. If a job is using a password file and needs to change a password, the password file contents can be replaced. Otherwise, to update the password the job will need to start using credentials. If this not acceptable, the plugin can work in the old mode by setting the system/environment property: com.ibm.team.build.credential.edit=true.

1.0.10

  1. On Linux, a build definition with a load directory starting with "/" (i.e. "/any/folder") used to be interpreted as a relative path, but is now correctly interpreted as an absolute path.  So, any build definition relying on the previous behavior need only prefix the load directory with a "." (i.e. "./any/folder").

18 Comments

  1. Really happy to see this plugin updated as we are also trying to use Jenkins along with RTC. However I met an issue while trying to check out code from the repository in a Jenkins job:

    RTC : checkout...
    RTC Checkout : Source control setup
    RTC Checkout : Accepting changes into workspace "xxx" ...
    RTC Checkout : Fetching files to fetch destination "/root/.jenkins/jobs/test_rtc_checkout/workspace" ...
    FATAL: RTC : checkout failure: Loading the directories in the file system would overwrite/remove existing directories.
    Loading the directories in the file system would overwrite/remove existing directories.
    /.project (requested to be loaded from both component CI and Core)

    com.ibm.team.build.internal.scm.SourceControlUtility$3: Status WARNING: com.ibm.team.filesystem.client code=2 Loading the directories in the file system would overwrite/remove existing directories. null children=[Status WARNING: com.ibm.team.filesystem.client code=0 /.project (requested to be loaded from both component CI and Core) null]
        at com.ibm.team.build.internal.scm.SourceControlUtility.updateFileCopyArea(SourceControlUtility.java:685)
        at com.ibm.team.build.internal.hjplugin.rtc.RepositoryConnection.checkout(RepositoryConnection.java:407)
        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:48)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:600)
        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:904)
        at hudson.FilePath.act(FilePath.java:877)
        at com.ibm.team.build.internal.hjplugin.RTCScm.checkout(RTCScm.java:843)
        at hudson.model.AbstractProject.checkout(AbstractProject.java:1369)
        at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:676)
        at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
        at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:581)
        at hudson.model.Run.execute(Run.java:1575)
        at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
        at hudson.model.ResourceController.execute(ResourceController.java:88)
        at hudson.model.Executor.run(Executor.java:241)
    Contains : 0 /.project (requested to be loaded from both component CI and Core)
    ERROR: RTC : checkout failure: Loading the directories in the file system would overwrite/remove existing directories.
    Loading the directories in the file system would overwrite/remove existing directories.
    /.project (requested to be loaded from both component CI and Core)

    Any clue?

  2. OK, just saw https://issues.jenkins-ci.org/browse/JENKINS-18284 , I wonder if there is a plan to make the enhancement to support using workspace directly.


  3. error message:

    连接失败:hudson.ClassicPluginStrategy$AntClassLoader2 cannot be cast to java.net.URLClassLoaderjava.lang.ClassCastException: hudson.ClassicPluginStrategy$AntClassLoader2 cannot be cast to java.net.URLClassLoader
    at com.ibm.team.build.internal.hjplugin.RTCFacadeFactory.newFacade(RTCFacadeFactory.java:160)
    at com.ibm.team.build.internal.hjplugin.RTCFacadeFactory.getFacade(RTCFacadeFactory.java:67)
    at com.ibm.team.build.internal.hjplugin.RTCScm$DescriptorImpl.checkConnect(RTCScm.java:483)
    at com.ibm.team.build.internal.hjplugin.RTCScm$DescriptorImpl.doCheckGlobalConnection(RTCScm.java:476)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:297)
    at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:160)
    at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:95)
    at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111)
    at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
    at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:684)
    at org.kohsuke.stapler.Stapler.invoke(Stapler.java:777)
    at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:239)
    at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53)
    at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:684)
    at org.kohsuke.stapler.Stapler.invoke(Stapler.java:777)
    at org.kohsuke.stapler.Stapler.invoke(Stapler.java:586)
    at org.kohsuke.stapler.Stapler.service(Stapler.java:217)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:96)
    at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:88)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
    at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
    at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:47)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:470)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:291)
    at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:877)
    at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:594)
    at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1675)
    at java.lang.Thread.run(Thread.java:662)

    anyone know where im going wrong ?

  4. Fetching files is very slow when Compare with old CLI based plugin. For example, below screen shot shows that it takes 25 seconds to accepting changes, 42m37s to fetch files. While with old plugin, it takes less than 3 min to finish whole building (including accept, load, compile). Can anyone explain why it is so slow?
    Activity LabelStart TimeActivity Duration   | Queueing build in Hudson/Jenkins | 00:00:00 | 0 s |

    Jazz Source Control setup

    00:00:07

    43 m 04 s

    Accepting changes

    00:00:08

    25 s

    Fetching files

    00:00:34

    42 m 37 s

  5. The plugin doesn't handle symbolic link properly, files with symbolic link always get updated even contents are not changed. 

  6. According to the post-build step limitation (JENKINS-18421), the plugin adds  RTCBuildResultUUID to the environment.  If this is true, it would great to have this info on the page.

  7. Hi Team,

    I'm new in CI. i followed this documentation but I'm not able to get it working.

    when click save on my job i get below error message, will appreciate any help.

    Thanks
    Failed to instantiate class com.ibm.team.build.internal.hjplugin.RTCScm from {"value":"1","overrideGlobal":false,"buildTool":"4.0.1","serverURI":"https://localhost:9443/jazz","timeout":"480","userId":"testuser","password":"","passwordFile":"","buildType":{"value":"buildWorkspace","buildWorkspace":"test workspace"}}

    Caused by:java.lang.RuntimeException: Failed to instantiate class com.ibm.team.build.internal.hjplugin.RTCScm from {"value":"1","overrideGlobal":false,"buildTool":"4.0.1","serverURI":"https://localhost:9443/jazz","timeout":"480","userId":"testuser","password":"","passwordFile":"","buildType":{"value":"buildWorkspace","buildWorkspace":"test workspace"}}

    at hudson.model.Descriptor.newInstance(Descriptor.java:558)
    at com.ibm.team.build.internal.hjplugin.RTCScm$DescriptorImpl.newInstance(RTCScm.java:116)

    1. HI,

      I think you are talking about WorkFlow job types, this support is available from 1.1.9.4 versions of the plugin. 

    2. Just for reference (although it's an old question):

      I'm using the checkout in plugin version 1.1.9.4 using this notation:

      checkout changelog: true, poll: true, scm: [$class: 'RTCScm', avoidUsingToolkit: false, buildTool: 'current', buildType:[value: 'buildDefinition', buildDefinition:'myBuildDefinitionName'] , credentialsId: '2345fge56zw_asdfasdf', overrideGlobal: true, serverURI: 'https://localhost:9443/ccm', timeout: 480]

      The /CCM in the URL might be it

  8. Just noticed an issue when a changeset is associated to two workitems, only one workitem is shown in the Recent Changes section of the jenkins job. All associated workitems should be listed. Still using 1.1.8, but don't see any bug fixes in the new versions.

  9. Found an issue with plug-in version 1.1.9.8

    The build toolkit folder is looked for in the master machine, even though the checkout happens in the slave machine.

    ERROR: Built toolkit directory not found at: C:\xxx\RTC\RTC-BuildSystem-Toolkit-Win-5.0.2\jazz\buildsystem\buildtoolkit

    This folder is available in slave machine but not available in master machine.

  10. This plugin breaks on Jenkins 1.655 or later. 

    See Jenkins-34117 for details.

    Update: This was fixed in 1.2.0.0

  11. I am using "Build Stream" for the Build Configuration which was introduced in 1.2.0.0. I have multiple Jenkins jobs that use the same Build Stream. The problem is each of these Jenkins jobs creates a snapshot comment with #<build number> under the Steam. So if two different jobs using the same Build Stream each have the same Jenkins build number, the job that happens second will fail because the snapshot comment already exists. Is there a way to modify the snapshot comments to prevent this conflict? Ideally I want to add the project name to the snapshot comment to prevent conflicts.

    I did some research and noticed the comment string is stored in the Messages.properties file in the teamconcert.jar. I can modify the value of RTCScm_build_label to change the comments but teamconcert.jar is locked by Jenkins so I cannot update it at build time.

    Any thoughts or ideas would be appreciated. Thanks.

    1. In 1.2.0.2, the snapshot naming scheme has changed for Build Stream configuration. The default snapshot name will be  <JobName>_#<build_number>. We have introduced an option to customize the snapshot  name as well.

  12. Is this the forum to ask for Help with Team Concert plugin?

    1. You can ask questions related to Team Concert Plugin on https://jazz.net/forum.

  13. Hi,

    Is there a way to get the properties, defined in RTC build definition property tab in, jenkins?

Write a comment…