Rational team concert license timeout

Prior to 1. From 1. Follow these steps to setup a Jenkins Build Definition and Jenkins Job to avoid a catch situation. 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. In Jenkins, create the job first using RTC for source control, but with no build definition.

Leave the Build Definition text box blank. See Creating a build engine. In RTC, create a build definition that uses the build engine created in step b and select the job created in step a. See Creating a build definition. Lastly, in Jenkins, open the Jenkins job and set the Build Definition field with the id of the build definition created in step c. Notice the "Build Configuration" dropdown. This replaces the radio buttons for build definition and build workspace prior to version 1.

See Dedicated build workspaces help topic to learn how to create a build workspace. To add a "Related Artifact" link to a Jenkins build in all the included work items, select the option Add Jenkins build link to accepted work items option. To load the jenkins build workspace using a snapshot, select "Build Snapshot" from the Build Configuration dropdown.

The following steps show how to configure a parent Jenkins job to trigger a downstream Jenkins job. The downstream job is configured to use SCM snapshot.

The parent job triggers the downstream job, passing a snapshot UUID that will be used to load the sources. 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.

Create a new job and with a string parameter named rtcBuildSnapshot. You can use any parameter name for this purpose. 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.

To load the jenkins build workspace using a stream, select "Build Stream" from the Build Configuration dropdown. 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. NOTE: For this configuration the RTC user configured globally or for this job needs to have permission to attach snapshots to a stream. The directory on the build machine under which the repository files will be loaded can be specified.

Load Policy field, added in 1. 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. 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. To add a Related Artifact link to a Jenkins build in all the included work items, select the option "Add Jenkins build link to accepted work items" option.

This applies to Repository Workspace and Stream configurations. The logic for computing of new changes varies for Build Definition, Repository Workspace and Stream configurations. In case of Stream, the snapshot from the previous build is compared against the stream.

If the previous build does not have a snapshot, then the build previous to that one is considered. Changes discarded in the flow target or changes created in the repository workspace, not delivered to the stream. Enter a schedule. Click the help button beside the "Schedule" field to get help with the syntax.

Click the Save button to save the settings and return to the job page. You can configure the job to build at a specific time, irrespective of whether there are new changes in the source code. To configure for Post Build Deliver,. Select Fail on Error , if you want the build to fail if post build deliver fails.

In a Pipeline job, add the following snippet before the end of the script to perform post build deliver as the last step of the build. For pipeline jobs, you can generate the snippet for Team Concert Plugin using the Pipeline snippet generator. See the help documentation for more information on how to create a snippet. In the snippet generator,.

Click the Sample Step dropdown and select checkout. Then select Rational Team Concert from the dropdown. Even if you do not choose to override global configuration for Team Concert Plugin defined in System Settings, the snippet generator will copy the values for serverUri , credentialsId and buildtoolkit copied from the global configuration in the snippet. If you copy this snippet into your pipeline script, it can create maintenance issues when you intend to change the global server URI, credentials and build toolkit.

If you intend to use the global settings for RTCScm configuration, then remove the following attributes in the snippet. If you are using declarative pipeline, then every agent directive will cause a checkout to happen in that agent using the same configuration as Pipeline Script from SCM. When using a build definition, stream or workspace configuration, this will cause an accept to happen in each of those cases, leading to different content being loaded in each agent. In the case of build definition, an additional build result will be created if the build is triggered from Jenkins.

This may or may not be what you want. If you want to prevent the extra checkout for every agent directive, add a options directive below the agent directive with the value skipDefaultCheckout true. Master and agent 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.

In the node configuration page, find the Node Properties section and check the Tool Locations check box. 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. NOTE: If you do not wish to override the tool location, then Team Concert Plugin will try to locate the toolkit at the same location specified in Global Tool configuration. Build toolkits can also be installed automatically on agents.

And labels can be used to match build toolkits to agents. However, a valid toolkit is required in the master node to perform connection tests to build artifacts and perform polling. You can capture logs from the Team Concert plugin to debug any problems that you may encounter. Enter a logger for com. Return to this log if a problem is ever experienced using this plugin. The log will help to identify the problem.

The environment variable com. Hover over the link of the node to configure. Choose Configure from the popup context menu. Supply com. Enter com. To configure debugging for a single job, add com. 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 an agent so if you need those logs, consider running on the master to get the detailed logs.

If you have turned on the variable com. Configuring logging for Team Concert plugin does not enable log messages from the build toolkit to appear in the Jenkins log recorder. To enable log messages from build toolkit to be output to a file on the Jenkins controller or any agent, refer to the steps in the wiki Capture log messages from EWM Build Toolkit on the Jenkins controller.

The following properties can be accesssed as environment variables in the build after Rational Team Concert source control step is completed. UUID of the snapshot created after accepting changes. Not set if no snapshot was created. Only set if the build is using a build definition.

UUID of the build definition being used by the build. An RTC build engine is not actually running, but some ant tasks need the engine id. User id of the RTC user that requested the build be started.

The name of the temporary Repository Workspace created during a build using Stream configuration. Apart from these built-in properties, when using Build definition configuration, all the build properties set in the build definition and potentially modified when requesting the build will be available as environment variables in the Jenkins build after the Team Concert plugin runs. In a freestyle job, after Team Concert Plugin completes downloading the source code to the Jenkins workspace, you can access the properties exported by Team Concert Plugin with the following syntax.

Team Concert Plugin exports some standard properties and user defined build properties only for Build definition configuration. For a list of builtin properties, refer to this section. In a build definition configuration, if the Jenkins build is started from RTC, you can access build properties set in the RTC build result in a pipeline build even before the checkout step runs.

These properties can be any of the RTC built-in properties set in the build result or user defined build properties. The actual value will be set by the RTC build result that starts the Jenkins build. The following built-in properties are available to the Jenkins build even before the checkout step runs.

For instance, consider the scenario where you want to know if the RTC build result that started this pipeline build is a personal build or not. First create a Job parameter "personalBuild" type is String in the Jenkins pipeline job and set the default value to false. Request a personal build in the RTC build definition associated with the Jenkins job.

In your pipeline script, you can check whether the RTC build is a personal build or not as follows. To access the buildRequesterUserId property in your script, define a new String parameter called "buildRequesterUserId" to the Jenkins job and set the default value to an empty string. Prop checkout step now returns a map that is populated by Team Concert plugin. For a list of built-in properties exported to the environment, see this section. Refer to Issue for the related issue.

You can access RTC Environment properties after the checkout step runs using the env object. As an example, after every checkout, you can save the snapshot UUID value into a separate variable as follows. Jenkins Developers forum post.

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.

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. 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. This can be used in a pipeline script to obtain snapshot UUID.

Therefore, currentBuild. The above code cannot be directly used in a pipeline script without an administrator whitelisting the APIs in Jenkins. 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. Then, in your pipeline script, you can write the following to get the snapshotUUID of the checkout step.

If you do not have Global Shared Library that is defined in your environment, see Extending with Shared Libraries for creating and accessing a shared library in your pipeline script.

A RTCBuildResultAction will be added to the build at the point where the library is checked out into the pipeline script. RTC support for symbolic links requires one or two additional libraries. 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. From the com. Take all the. Place them directly in a directory eg. 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.

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. 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". When loadPolicy is set to useComponentLoadConfig, you can either choose to load all components or exclude some components by setting the value for "componentLoadConfig" to either "loadAllComponents" or "excludeSomeComponents".

The load policy field for RTC build definition can be set only using the 6. Component load rules can also be specified through dynamic load rules extension. Dynamic load rules feature is supported across all build configurations. 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.

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 backwards 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. You can change the load policy by migrating your old build definitions from the Eclipse client to use the new load format.

Before 1. 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.

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. You can configure a pipeline job to poll on a RTC build definition or a repository workspace but skip downloading the sources when the pipeline build runs by using the option polling-only. The snapshot should be owned by the repository workspace configured in the build definition.

To enable the polling-only option, add the text "pollingOnly: true" to the checkout step. If you prefer to use the snippet generator to generate a checkout step with the polling-only option, follow the steps below:. To generate a changelog, enter the variable that references the snapshot UUID. The step provides the following tasks. Once the build request is successfully created, the step returns the build result UUID in an object that is available in pipeline script.

To add a new property or override the value of an existing property when requesting a build, select "Add or Override Properties".

Click "Add Property" and add the name and value of the property to add to or override in the build request. The following snippet requests a build with one new property and a few deleted properties and prints the build result UUID after rtcBuild step completes requesting a build in RTC. The following snippet requests a build, prints the build result UUID after rtcBuild step completes requesting a build in RTC and adds a link of the build result to the Jenkins pipeline build.

To make the pipeline build pause until a RTC build to change state or a timeout expires, use the Wait for Build task. Once the step completes successfully, one of the following is true:. The different states of the build result on which the step will wait. If the build result enters into one of the states, then the step returns from execution. The time in seconds up to which this step will wait.

By default, the step waits forever to reach the specified build states. For longer builds, it is recommended to wait for a shorter timeout and use looping constructs available in pipeline script to retry.

Whether or not the step timed out. If this value is false, then the status of the build is one of the build states that the step waited on. This value is usually a parameter which is obtained from requesting a build. In the Build States to wait for text box, enter the states to wait for separated by a comma. In Wait timeout in seconds text box, enter the wait timeout in seconds. This value should be greater than zero. The default value is -1 which makes the step wait until the build result enters into the specified states.

Once the step completes, it prints the following fields from the return value. The Developer for IBM Enterprise Platforms license is designed for professional developers actively participating in the project. It is designed for development teams targeting System z and Power Systems platforms.

The Developer for Workgroups license is similar to the Developer license except that it does not include support for distributed Software Configuration Management and is limited to 50 authorized users per server or server group.

It is designed for departmental teams and budgets. Organizations can grow beyond 50 developers by adding Developer or Developer for IBM Enterprise Platform licenses, though the distributed SCM restriction will remain for all licenses on that server or server group.

As mentioned above, the RQM license types change from the 2. The Quality Professional license is designed for quality professionals actively participating in the project. This license also provides read access to Software Configuration Management and Automation Build System capabilities unless otherwise restricted by role-based process permissions. Again, as mentioned above, the RRC license types change from the 2.

The Analyst license is designed for analysts actively participating in the project. This license also provides read access to Software Configuration Management, Test Management and Automation Build System capabilities unless otherwise restricted by role-based process permissions.

Authorized User and Floating User Single Install are available both as perpetual licenses and term licenses. Token licenses are available only as term. Note, the explanations below include several illustrations using RTC. The license activation kits are available for download on the RTC download pages for the respective releases, 3. These are Authorized User Single Install only. Because the license control is managed at the Jazz Team Server, Terry, Carlos, or Alan can simultaneously access a JTS instance from multiple different computers and require only one license for access on that JTS instance.

Figure 2 Authorized user licensing distinctly managed. Figure 3 Authorized user license centrally managed. Once the activation kit is installed, the number of licenses purchased is entered by the administrator. This process is similar how it has been in earlier releases of the CLM products.

Figure 4 Adding an Authorized user license. Figure 6 Assigning an Authorized user license to a user id. If not, no license is granted. One significant enhancement starting with RTC 3. If a user is logged onto RTC, e. Figure 7 Simple Floating license topology. To retrieve the name or contentId of the log, use the "List Logs" task. You can download an artifact using the artifact's name or content ID.

To retrieve the name or contentId of the artifact, use the "List Artifacts" task. If the build result does not have such a contribution, then the task returns empty values for snapshot name and UUID.

The timeout period in seconds for establishing a connection to the Jazz repository when running this step. Default value is seconds. Currently, post build deliver is performed only if a build definition is used as the build configuration. The step uses the post build deliver configuration information from the build definition. If 'Include in changelog' is enabled for an SCM source, then when a build occurs, the changes from that SCM source will be included in the changelog.

If 'Include in changelog' is disabled, then when a build occurs, the changes from this SCM source will not be included in the changelog. If 'Include in polling' is enabled or 'Include in changelog' is enabled, then when polling occurs, the job will be started if changes are detected from this SCM source.

If 'Include in polling' is disabled and 'Include in changelog' is disabled, then when polling occurs, changes that are detected from this repository will be ignored.