Build properties
You can define certain build script properties, such as ECLIPSE_HOME, from the properties of the build definition or build engine.
User-defined properties
Properties that you define in the build definition, build engine, or request build dialog box are written to the output properties file that you specify in the Properties file field in the build definition (for Command Line and Ant builds), and are automatically available to Ant scripts (for Ant builds).
You can use variables in property values by specifying the ${propertyName}
format. For example, if you create a build engine property named toolsdir
with a value of /home/build/tools, you can reference the property as
${toolsdir} from property fields in the Build Definition editor. Before the
build starts, the Jazz® Build Engine
substitutes the property variables and their substituted form is provided to the build script.
You can define a hidden property, whose value is masked in the user interface. Hidden properties are supported only in the following build definitions:
- Ant
- Command line
- Maven
- Jazz Build for Engineering Workflow Management client for Microsoft Visual Studio IDE
Properties supported by the Jazz Build Engine
| Property name | Description |
|---|---|
buildLabelPrefix |
Specifies a prefix for the build label, such as I for integration. If you define this property in your build definition or build engine, the value is prepended to the label that the Jazz Build Engine generates. For example, I20080215-1234. |
requestFilter |
An &-separated list of name/value pairs of properties to match when looking up the next request from a build queue. Currently only personalBuild property is supported, so valid values are personalBuild=true and personalBuild=false. |
team.build.reportStatistics |
Specifies whether to collect and report statistics related to the service calls made by the Jazz Build Engine. The statistics are similar to the ones collected by the Eclipse client using Metronome. If you define and set this property to true on your build definition or build engine, information about the service calls, such as how long they took, are collected and published as logs in the build result. The logs are in a human-readable report and comma separated value (csv) format. |
Properties to control build requests
The table below describes built-in properties that are available for you to control the build request.
| Attribute | Description |
|---|---|
|
team.build.properties.disableUIEdit |
When set to true in the build definition, this property disables editing or adding or removing build properties in the build request dialog of Engineering Workflow Management for Eclipse, Web, and Visual Studio clients. |
Post-build Deploy properties
The table below describes built-in properties that are available when you use the Post-build Deploy option.
| Attribute | Description |
|---|---|
team.udeploy.debug |
Whether to output debug tracing during Post-build Deploy. Value is true or false. Default is false. |
team.udeploy.timeout |
UrbanCode® Deploy connection timeout (in seconds). Default is 480 (8 minutes). |
Built-in properties
There are several built-in properties available when you use the Jazz Build Engine. Use these properties if you use the Jazz Ant tasks to publish information to the repository. For example, you need the repositoryAddress and buildResultUUID properties to use the StartBuildActivityTask.
The table below describes built-in properties that are available when you use the Jazz Build Engine.
| Attribute | Description |
|---|---|
buildEngineId |
The friendly identifier for the build engine (not the UUID). |
buildEngineHostName |
The host name of the build engine. |
buildLabel |
The build label that was generated by the Jazz Build Engine. For example, 20080215-1234. |
buildResultUUID |
The unique identifier for the build result. Any task that
publishes progress or information to a build result must provide this
attribute. The value for the attribute is passed to your build script
in the |
buildRequesterUserId |
The user identifier (not the UUID) that requested the build. |
requestUUID |
The unique identifier for the build request. |
buildDefinitionId |
The friendly identifier for the build definition (not the UUID). |
repositoryAddress |
The address of the Jazz repository where the build request originated. For example, http://example.com/jazz. |
personalBuild |
Indicates that the current build is a personal build. The property is only set if the build is a personal build. |
|
teamBuildEngineVersion |
The version of the Jazz Build Engine. |
* |
All properties that are defined in the build engine editor are available to the Ant script. |
* |
All properties that are defined on the Properties page of the build definition editor are available to the Ant script. These properties override the build engine properties if there is a property name conflict. |
* |
All properties defined in the Build Properties section of the Request Build dialog box are available to the Ant script. These properties override the build definition properties if there is a property name conflict." |
The table below describes built-in properties that are available when you use Build Forge® build engines.
| Attribute | Description |
|---|---|
buildforge.createRTCBuild |
Whether to create an EWM build result for a build initiated in Build Forge. The default is true. |
buildforge.collectLogsPerStep |
Whether to collect step logs as each step completes. If false, the logs are only collected at the end of the build. The default is true. |
buildforge.socketTimeout |
The socket timeout for the socket connection to Build Forge, in seconds. The default is 30. |
buildforge.preBuildScmCheck |
Whether to check for SCM changes (for scheduled builds only) before starting the build (when using the Jazz Source Control option). The default is true. |
Engineering Workflow Management source control properties for build definitions
The table below describes source control properties that are available on the Jazz Source Control page of a build definition.
| Attribute | Description |
|---|---|
team.scm.acceptBeforeFetch |
Boolean property corresponding to the Accept latest changes before loading option. |
team.scm.buildOnlyIfChanges |
Boolean property corresponding to the Build only if there are changes accepted field. |
team.scm.changesAccepted |
String property giving the number of changes accepted; only set if changes were accepted. |
|
team.scm.componentLoadConfig |
String property whose value can be either loadAllComponents or excludeSomeComponents. When team.scm.loadPolicy is set to useComponentLoadConfig, this property determines whether to load all components or exclude some components during load. The default value is loadAllComponents. |
team.scm.componentLoadRules |
String property that mentions the load rule file to use when team.scm.loadPolicy is set to useLoadRules. Specify the itemId of the component and the load rule file in the format component=<component-itemId> fileitem=<loadRuleFile-itemId>. |
|
team.scm.createFoldersForComponents |
Boolean property that determines if component roots will be loaded as directories in the file system when team.scm.loadPolicy is set to useComponentLoadConfig. |
team.scm.deleteDestinationBeforeFetch |
Boolean property that determines if the load directory should be deleted in every build. When set to true, the load directory is deleted in every build. The default value is false. |
|
team.scm.expandKeywords |
Indicates that keywords in text files are to be expanded when encountered. For more information, see Keyword expansion. |
team.scm.fetchDestination |
String property corresponding to the Load directory field.
Note: It is advised to avoid using blanks or $ in the path as these characters (or
their national language equivalents) can cause inconsistent results.
|
team.scm.includeComponents |
Boolean property indicating whether loadComponents specifies components to include (true) or exclude (false); currently always false. |
team.scm.loadComponents |
String property that mentions the list of components to include or exclude when team.scm.loadPolicy is set to useComponentLoadConfig. |
|
team.scm.loadMethod |
String property whose value can be one of fullLoad, incrementalLoad, or optimizedIncrementalLoad. This property works along with the team.scm.deleteDestinationBeforeFetch boolean property. When set to fullLoad and team.scm.deleteDestinationBeforeFetch is set to true , then the load directory is deleted in every build and all the files from the repository workspace are fetched. When set to incrementalLoad and team.scm.deleteDestinationBeforeFetch is set to false, then the load directory is not deleted; only modified files are fetched from the repository, local changes are reverted, and untracked files are deleted. When set to optimizedIncrementalLoad and team.scm.deleteDestinationBeforeFetch is set to false, then the load directory is not deleted; only modified files are fetched from the repository, local changes are not reverted, and untracked files are not deleted. The default value is incrementalLoad. |
|
team.scm.loadPolicy |
String property corresponding to the Load Policy field. Its value can be either useComponentLoadConfig or useLoadRules. When set to useComponentLoadConfig the entire contents of all the components, or some of the components in the repository workspace, are loaded depending on the value of the team.scm.componentLoadConfig property. When set to useLoadRules, the load rule file mentioned in the team.scm.componentLoadRules property is used to determine the components and the contents of the components to load. The default value is useComponentLoadConfig. |
team.scm.maxContentThreads |
The number of threads used to fetch files during a load. If 0 is provided, it uses no background threads (each file is fetched in sequence, in the main build loop thread). The default is 10. |
team.scm.preBuildScmCheck |
Whether to check for SCM changes (for scheduled builds only) before starting the build (when using the Engineering Workflow Management source control option with Jazz Build Engine). The default is false. |
|
team.scm.preserveFileTimestamps |
When repository files are loaded, the timestamp from the file in the repository is used as the timestamp on disk (true). |
team.scm.snapshotUUID |
String property giving the snapshot UUID; only set if snapshot was created. |
team.scm.workspaceUUID |
String property corresponding to the Workspace field, or the developer workspace in the case of a personal build; gives the workspace UUID. |