An overview of the different build configurations supported by the Team Concert Jenkins plug-in
This page describes a usage or software configuration that is not supported by IBM. Using the Team Concert Jenkins plug-in, you can configure your Jenkins jobs to use Rational Team Concert (RTC) source control and, optionally, report information back to Rational Team Concert builds. The plug-in integrates Jenkins with RTC using the richer features of the build toolkit. This plug-in is different from the other Rational Team Concert plug-in for Jenkins which uses SCM CLI to integrate with RTC.
This article provides an overview of the different build configurations supported by the Team Concert Jenkins plug-in 1.2.0.1. For instructions on how to setup and configure the plug-in, refer to Team Concert Jenkins plug-in wiki.
About Jenkins
While Jenkins can be described as a Continuous Integration server, it’s extensible architecture makes it usable in any kind of automation scenarios. Jenkins can be extended via its plug-in architecture.
About Team Concert Jenkins plug-in
The Team Concert Jenkins plug-in contributes to the source control extension of Jenkins, thereby providing RTC SCM as one of the source control options that can be used from a Jenkins job.
The Team Concert Jenkins plug-in works with build toolkit versions starting from 4.0.7. The plug-in can be downloaded from here.
Terminology
- Jenkins job – Runnable tasks that are controlled/monitored by Jenkins. Can be related to an RTC build definition.
- Jenkins build – Result of one run of a Jenkins job. Can be related to an RTC build result.
- Master – System that hosts and runs a Jenkins instance.
- Slave – Slaves are systems that are set up to build jobs for a master. Jenkins runs a separate program called “slave agent” on slaves. When slaves are registered to a master, a master starts distributing the load to slaves.
- Node – The term node is used to refer to all the machines that are part of the Jenkins grid, slaves and master.
- Workspace – Disposable directory on a Node used as a working directory for building.
- Build Configuration – Generic term used to refer to the different RTC SCM and Build artifacts that forms the basis of the RTC SCM configuration in a Jenkins job.
- Build Workspace – An RTC repository workspace configured to be loaded in the builds.
An overview of the integration
The Team Concert Jenkins plug-in integrates Jenkins with RTC source control and build capabilities.
With the source control integration, a workspace can be loaded from one of the following SCM artifacts:
- Repository Workspace
- Stream
- Snapshot
When using the build configurations that tap into the source control integration, a Jenkins job cannot be associated with an RTC build definition and hence requesting a build from Jenkins will not create a corresponding build result entry in RTC.
With the build integration, a Jenkins job can be associated with an RTC build definition, facilitating Jenkins builds to be managed from both ends and also take advantage of the traceability provided across RTC work items, builds, and change sets. The workspace is loaded using the Jazz Source Control options, which supports only loading from a repository workspace, specified in the build definition.
Supported Build Configurations
Load using a Build Definition
When a Jenkins job is configured to load using a build definition, Jenkins builds can be requested from Jenkins as well as the corresponding RTC build definition. If you are an RTC user used to RTC builds and would like to use Jenkins, this might be an easy way to get started.
Note: There should always be a one to one mapping between the build workspace and the RTC build definition.
The Team Concert Jenkins plug-in publishes source control build activities to the RTC build result. Additionally, when a Jenkins build is requested from RTC, the console log from Jenkins is made available from the RTC build result. Requesting a build from Jenkins doesn’t publish the log to the corresponding RTC build result, though.
When an RTC build is scheduled to run at specific intervals or at a stipulated time, a corresponding Jenkins build is also started.
You can also request a personal build from the RTC build definition. This triggers a Jenkins build that loads from the RTC repository workspace specified in the RTC personal build request.
Since there is an RTC build associated with each of the Jenkins build, this configuration can take advantage of several other RTC features like build health reports; build completion notifications through email, feeds, and toast popups; traceability provided across RTC work items, builds, and change sets; and many more.
For instructions on how to define a Jenkins build engine and build definition in RTC, refer to Integrating Rational Team Concert and Hudson/Jenkins build engine type.
Load from a Repository Workspace
A Jenkins job configured to load from a repository workspace can be used for continuous integration builds where there is a dedicated build workspace that flows with a team’s integration stream.
If you want to make any automated updates, like copyright changes and deliver it as part of the builds, it can be done in this configuration.
Note: The Team Concert Jenkins plug-in doesn’t support check-in and delivering the changes to the stream, SCM CLI can be used for this purpose.
If you want to load your workspace from components included in different streams, you can create an RTC repository workspace with components scoped to flow with appropriate streams and specify it as your build workspace in the Jenkins job.
Note: Using the same repository workspace across different jobs is not recommended. Running concurrent builds of the same job is also not recommended for this configuration.
Load from a Stream
A Jenkins job configured to load from a stream can be used to continuously validate the integration state of a team’s stream.
Continuous validation of a team’s stream can be achieved by configuring polling at short intervals. Load from a stream configuration works well with continuous integration builds configured with polling, as concurrent builds of the same job can be run in this configuration.
If you are a Jenkins user and would like to use RTC source control, this might be the configuration that you would start with.
Load from a Snapshot
A Jenkins job configured to load from a snapshot can be used to load and build a consistent configuration across concurrent runs of different jobs.
This can be achieved by defining a upstream job, that loads from a workspace/stream or using a build definition, to start multiple downstream jobs passing the snapshot created in it’s run.
Note: The uuid of the snapshot, created in the builds of other configurations, is available as the build environment property team_scm_snapshotUUID.
Polling is irrelevant for this configuration. Change log information is also not published in the builds.
Loading from a snapshot that is directly specified in the job configuration, either by name or UUID, is also supported, thus making it possible to recreate the build artifacts from a different build.
In the following sections, we’ll discuss some of the features supported by the Team Concert Jenkins plug-in in greater detail.
Traceability from Jenkins builds to RTC change sets and work items
The Team Concert Jenkins plug-in creates a snapshot of the SCM configuration loaded in the build and publishes a link to this snapshot in the change log for the Jenkins build. The change log also includes the list of change sets included in the build. The change log is annotated with the web UI links to the included change sets and work items associated with those change sets, under the corresponding components.
So, from a Jenkins build one can determine which change sets and work items were included in the build and also navigate to the corresponding artifacts, in RTC web UI.
The traceability from Jenkins builds to RTC change sets and work items is supported across all the build configurations, but load from a snapshot configuration.
Traceability from RTC work items to Jenkins builds
When a Jenkins job is configured to load using an RTC build definition, the Team Concert Jenkins plug-in creates an RTC build result for every Jenkins build. The plug-in links the RTC build result with the Jenkins build and also with the corresponding Jenkins job. The link to the Jenkins job turns out to be useful if the Jenkins build is deleted.
The Team Concert Jenkins plug-in also contributes the snapshot created in the Jenkins build as well as the work items included in the Jenkins build to the RTC build result. This provides traceability information from RTC work items to the Jenkins build through the RTC build result associated with the work items.
So, with the build definition configuration one can achieve bi-directional traceability i.e. in addition to finding out the work items included in a Jenkins build, one can also determine the Jenkins build that picked up the changes associated with an RTC work item.
Note: This bi-directional traceability is supported only in the build definition configuration. All other configurations support only the traceability from Jenkins builds to RTC change sets and work items.
Polling
When SCM polling is activated for a Jenkins job, a build is scheduled only when there is an SCM change since the last build.
The Team Concert Jenkins plug-in supports this polling feature by determining if there is any RTC SCM change, based on the SCM artifact configured in the Jenkins job, since the last build.
Polling is supported by all build configurations but snapshot.
Summary
In this article we discussed about the different build configurations supported by the Team Concert Jenkins plug-in along with the suggested usage scenarios for each of them. Depending upon your usage you might find these configurations to be applicable in other scenarios too. We also discussed in detail about some of the features supported by the Team Concert Jenkins plug-in.
For more information
- Integrating Rational Team Concert and Hudson/Jenkins build engine type
- Team Concert Jenkins plug-in wiki
- Jenkins Terminology
- Jenkins Home Page
Copyright © 2016 – IBM Corporation
Yes