The task retrieves configuration information for the specified Build Orchestrator build. The type of information retrieved is controlled by the inclusion of the following as sub-elements within the element:
| Action Element | Retrieves action definition details defined in the orchestrated build. | |
| Dependent Element | Retrieves information on the dependent builds defined in the orchestrated build. | |
| DependsOn Element | Retrieves information on the "depends on" builds defined in the orchestrated build. | |
| Housekeeping Element | Retrieves information on the housekeeping builds defined in the orchestrated build. | |
| Primary Element | Retrieves information on the primary builds defined in the orchestrated build. | |
| Secondary Element | Retrieves information on the secondary builds defined in the orchestrated build. |
At least one sub-element listed above must be specified to retrieve configuration information for the Build Orchestrator build. No error is generated if sub-elements are omitted.
The task supports Team Build Attributes, Build Extensions Debugging Attributes, Build Extensions General Attributes, as well as, its own task specific attributes. Click on a link for more information on the common attributes.
The following table describes the task specific attributes for the task:
| Task Specific Attributes | ||
| Attribute | Description | Required |
| buildResultUUID |
Specify the UUID of a Build Orchestrator build result. The value of this attribute is typically ${buildResultUUID} because the property is built-in when using the Jazz Build Engine or Rational Build Agent. The ${buildResultUUID} property will be automatically retrieved from the Ant environment if this attribute is not specified. This attribute is used to identify the Build Orchestrator build definition to reference.
|
Yes* |
| orchestratorBuildId | Specify the ID of the Build Orchestrator build definition. This attribute is used to identify the Build Orchestrator build definition to reference. | Yes* |
The Action Element is specified to retrieve action definition details defined in the Build Orchestrator build. The following table describes the valid Action Element attributes:
| Action Element Attributes | ||
| Attribute | Description | Required |
| fetch |
Specify true to retrieve fetch phase actions. The default is false; fetch phase actions will not be retrieved.
|
No |
| postBuild |
Specify true to retrieve post-build phase actions. The default is false; post-build phase actions will not be retrieved.
|
No |
| preBuild |
Specify true to retrieve pre-build phase actions. The default is false; pre-build phase actions will not be retrieved.
|
No |
| prefix |
Specify a prefix value for the Ant properties that will be created to hold the retrieved data. Each Ant property created for an action entry will start with this prefix. For example, if prefix="action" is specified, the property name for the type of action to take would be: action.n.type where n is the array index of the action entry.
|
Yes |
| property |
Specify the name of the property in which to return the array index string for the values returned. Each index in the string can be used to access a set of action entry values. For example, if four action entries are retrieved, this property will have a value of "1,2,3,4". Each member in this list can be substituted for the value of n above. Combining this example and the prefix example, for the first entry in the list, 1, the property name for the type of action to take would be: action.1.type.
|
Yes |
When an Action Element is specified and the Build Orchestrator build has actions defined, action definition details are returned to the Ant environment in the property arrays described in the following table:
| Action Element Properties | ||
| Name | Value | Description |
| <prefix>.<index>.type |
COPY
|
The type of action to take. The following lists the supported actions:
|
| <prefix>.<index>.<actionArg1> |
The first argument for the specified action:
|
|
| <prefix>.<index>.<actionArg2> |
The second argument for the specified action:
|
|
The following example is extracted from the BuildOrchestratorSetup macro. The code segment listed here calls the buildOrchestrator task to retrieve action information, creates a set of build properties, loops through the actions via the index property returned by the buildOrchestrator task (actionCount), and for each action it creates a set of properties for the action entry, with the prefix and index portion stripped from the property names, and finally it calls another macro (BuildOrchestrator.Action) to process the action:
<xt:buildOrchestrator
buildResultUUID="@{buildResultUUID}"
passwordFile="@{passwordFile}"
repositoryAddress="@{repositoryAddress}"
userId="@{userId}"
verbose="@{verbose}"
>
<xt:actions fetch="true" prefix="@{prefixAction}" property="actionCount"/>
</xt:buildOrchestrator>
<echo level="debug">actionCount: ${actionCount}</echo>
<propertyset id="BuildOrchestratorProperties.Build">
<propertyref prefix="team.enterprise."/>
</propertyset>
<echo level="debug">Properties.Build: ${toString:BuildOrchestratorProperties.Build}</echo>
<ac:for param="i" list="${actionCount}">
<sequential>
<propertyset id="BuildOrchestratorProperties.Entry">
<propertyref prefix="@{prefixAction}@{i}."/>
<mapper type="glob" from="@{prefixAction}@{i}.*" to="*"/>
</propertyset>
<echo level="debug">Properties.Entry: ${toString:BuildOrchestratorProperties.Entry}</echo>
<antcall target="BuildOrchestrator.Action">
<param name="action.activityLabel" value="@{activityLabel}"/>
<param name="action.buildResultUUID" value="@{buildResultUUID}"/>
<param name="action.parent" value="@{parent}"/>
<propertyset id="BuildOrchestratorProperties.Action">
<propertyset refid="BuildOrchestratorProperties.Build"/>
<propertyset refid="BuildOrchestratorProperties.Entry"/>
</propertyset>
</antcall>
</sequential>
</ac:for>
The Dependent Element is specified to retrieve information on dependent builds defined in the Build Orchestrator build. Dependent builds are builds that depend on the successful completion of another orchestrated build. The following table describes the valid Dependent Element attributes:
| Dependent Element Attributes | ||
| Attribute | Description | Required |
| prefix |
Specify a prefix value for the Ant properties that will be created to hold the retrieved data. Each Ant property created for a dependent build entry will start with this prefix. For example, if prefix="dependent" is specified, the property name for the build ID would be: dependent.n.buildId where n is the array index of the dependent entry.
|
Yes |
| property |
Specify the name of the property in which to return the array index string for the values returned. Each index in the string can be used to access a set of build entry values. For example, if four build entries are retrieved, this property will have a value of "1,2,3,4". Each member in this list can be substituted for the value of n above. Combining this example and the prefix example, for the first entry in the list, 1, the property name for the build ID would be: dependent.1.buildId.
|
Yes |
When a Dependent Element is specified and the Build Orchestrator build has dependent builds defined, build definition details are returned to the Ant environment in the property arrays described in the following table:
| Dependent Element Properties | ||
| Name | Value | Description |
| <prefix>.<index>.buildId | buildId | The build ID of the dependent build. |
| <prefix>.<index>.dependsOn | A comma separated list of build IDs of builds that are prerequisites to the dependent build. | |
| <prefix>.<index>.dependsOn.done | A comma separated list of "done file" names that represent the successful completion of a prerequisite build. | |
The following example is extracted from the BuildOrchestratorCheck macro. The code segment listed here calls the buildOrchestrator task to retrieve dependent information, creates a set of build properties, loops through the dependent builds via the index property returned by the buildOrchestrator task (dependentCount), and for each dependent build it checks for the required "done files", and if all are present, sets the dependentReady property to true:
<xt:buildOrchestrator
orchestratorBuildId="@{orchestratorBuildId}"
passwordFile="@{passwordFile}"
repositoryAddress="@{repositoryAddress}"
userId="@{userId}"
verbose="@{verbose}"
>
<xt:dependent prefix="@{prefixDependent}" property="dependentCount"/>
<xt:housekeeping prefix="@{prefixHousekeeping}" property="housekeepingCount"/>
</xt:buildOrchestrator>
<echo level="debug">dependentCount: ${dependentCount}</echo>
<echo level="debug">housekeepingCount: ${housekeepingCount}</echo>
<propertyset id="BuildOrchestratorProperties.Build">
<propertyref prefix="team.enterprise."/>
</propertyset>
<echo level="debug">Properties.Build: ${toString:BuildOrchestratorProperties.Build}</echo>
<local name="dependentStage"/>
<local name="housekeepingStage"/>
...
<!-- Dependent builds -->
<ac:for param="i" list="${dependentCount}">
<sequential>
<echo level="debug">buildId: ${@{prefixDependent}@{i}.buildId}</echo>
<echo level="debug">dependsOn: ${@{prefixDependent}@{i}.dependsOn}</echo>
<echo level="debug">dependsOn.done: ${@{prefixDependent}@{i}.dependsOn.done}</echo>
<local name="dependentToken"/>
<script language="javascript">
<![CDATA[
var stringValue = project.getProperty("@{prefixDependent}@{i}.dependsOn");
project.setProperty("dependentToken",stringValue.split(",").length);
]]>
</script>
<echo level="debug">dependentToken: ${dependentToken}</echo>
<local name="dependentReady"/>
<ac:if>
<length string="${@{prefixDependent}@{i}.dependsOn}" when="greater" length="0"/>
<ac:then>
<condition property="dependentReady">
<resourcecount when="equal" count="${dependentToken}">
<fileset dir="@{doneDirectory}" includes="${@{prefixDependent}@{i}.dependsOn.done}"/>
</resourcecount>
</condition>
</ac:then>
<ac:else>
<property name="dependentReady" value="true"/>
</ac:else>
</ac:if>
<echo level="debug">dependentReady: ${dependentReady}</echo>
...
</ac:for>
The DependsOn Element is specified to retrieve information on "depends on" builds. DependsOn builds are builds that some Dependent or Housekeeping build depends on. The following table describes the valid DependsOn Element attributes:
| DependsOn Element Attributes | ||
| Attribute | Description | Required |
| buildDefinitionId | Specify the ID of the build definition to check for dependencies. | Yes |
| prefix |
Specify a prefix value for the Ant properties that will be created to hold the retrieved data. Each Ant property created for a dependsOn build entry will start with this prefix. For example, if prefix="dependsOn" is specified, the property name for the build ID would be: dependsOn.n.buildId where n is the array index of the dependsOn entry.
|
Yes |
| property |
Specify the name of the property in which to return the array index string for the values returned. Each index in the string can be used to access a set of build entry values. For example, if four build entries are retrieved, this property will have a value of "1,2,3,4". Each member in this list can be substituted for the value of n above. Combining this example and the prefix example, for the first entry in the list, 1, the property name for the build ID would be: dependsOn.1.buildId.
|
Yes |
When a DependsOn Element is specified and the Build Orchestrator build finds that other builds have a dependency on the specified build, dependency details are returned to the Ant environment in the property arrays described in the following table:
| DependsOn Element Properties | ||
| Name | Value | Description |
| <prefix>.<index>.dependent | A comma-separated list of IDs for the dependent builds that are dependent on the specified build. | |
| <prefix>.<index>.housekeeping | A comma-separated list of IDs for the housekeeping builds that are dependent on the specified build. | |
The following example is extracted from the BuildOrchestratorClear macro. The code segment listed here calls the buildOrchestrator task to retrieve "depends on" information for the specified build and if any is found it deletes the "done file" and "submitted file" associated with the dependent or housekeeping build:
<xt:buildOrchestrator
orchestratorBuildId="@{orchestratorBuildId}"
passwordFile="@{passwordFile}"
repositoryAddress="@{repositoryAddress}"
userId="@{userId}"
verbose="@{verbose}"
>
<xt:dependsOn buildId="@{buildDefinitionId}" prefix="@{prefixDependsOn}" property="dependsOnFound"/>
</xt:buildOrchestrator>
<echo level="debug">dependsOnFound: ${dependsOnFound}</echo>
<ac:if>
<istrue value="${dependsOnFound}"/>
<ac:then>
<ac:for list="${@{prefixDependsOn}dependent}" delimiter="," param="buildId">
<sequential>
<DeleteFileDone buildId="@{buildId}" doneDir="@{doneDirectory}" label="@{activityLabel}.ClearDoneFile"/>
<DeleteFileSubmitted buildId="@{buildId}" doneDir="@{doneDirectory}" label="@{activityLabel}.ClearDoneFile"/>
</sequential>
</ac:for>
<ac:for list="${@{prefixDependsOn}housekeeping}" delimiter="," param="buildId">
<sequential>
<DeleteFileDone buildId="@{buildId}" doneDir="@{doneDirectory}" label="@{activityLabel}.ClearDoneFile"/>
<DeleteFileSubmitted buildId="@{buildId}" doneDir="@{doneDirectory}" label="@{activityLabel}.ClearDoneFile"/>
</sequential>
</ac:for>
</ac:then>
</ac:if>
The Housekeeping Element is specified to retrieve information on housekeeping builds. Housekeeping builds are builds that perform some sort of housekeeping process and execute after all Primary, Secondary, and Dependent builds have successfully completed. The following table describes the valid Housekeeping Element attributes:
| Housekeeping Element Attributes | ||
| Attribute | Description | Required |
| prefix |
Specify a prefix value for the Ant properties that will be created to hold the retrieved data. Each Ant property created for a housekeeping build entry will start with this prefix. For example, if prefix="housekeeping" is specified, the property name for the build ID would be: housekeeping.n.buildId where n is the array index of the housekeeping entry.
|
Yes |
| property |
Specify the name of the property in which to return the array index string for the values returned. Each index in the string can be used to access a set of build entry values. For example, if four build entries are retrieved, this property will have a value of "1,2,3,4". Each member in this list can be substituted for the value of n above. Combining this example and the prefix example, for the first entry in the list, 1, the property name for the build ID would be: housekeeping.1.buildId.
|
Yes |
When a Housekeeping Element is specified and the Build Orchestrator build has housekeeping builds defined, build definition details are returned to the Ant environment in the property arrays described in the following table:
| Housekeeping Element Properties | ||
| Name | Value | Description |
| <prefix>.<index>.buildId | buildId | The build ID of the housekeeping build. |
| <prefix>.<index>.dependsOn | A comma separated list of build IDs of build IDs that are prerequisites to the housekeeping build. | |
| <prefix>.<index>.dependsOn.done | A comma separated list of "done file" names that represent the successful completion of a prerequisite build. | |
The following example is extracted from the BuildOrchestratorCheck macro. The code segment listed here calls the buildOrchestrator task to retrieve housekeeping information, creates a set of build properties, loops through the housekeeping builds via the index property returned by the buildOrchestrator task (housekeepingCount), and for each housekeeping build it checks for the required "done files", and if all are present, sets the housekeepingReady property to true:
<xt:buildOrchestrator
orchestratorBuildId="@{orchestratorBuildId}"
passwordFile="@{passwordFile}"
repositoryAddress="@{repositoryAddress}"
userId="@{userId}"
verbose="@{verbose}"
>
<xt:dependent prefix="@{prefixDependent}" property="dependentCount"/>
<xt:housekeeping prefix="@{prefixHousekeeping}" property="housekeepingCount"/>
</xt:buildOrchestrator>
<echo level="debug">dependentCount: ${dependentCount}</echo>
<echo level="debug">housekeepingCount: ${housekeepingCount}</echo>
<propertyset id="BuildOrchestratorProperties.Build">
<propertyref prefix="team.enterprise."/>
</propertyset>
<echo level="debug">Properties.Build: ${toString:BuildOrchestratorProperties.Build}</echo>
<local name="dependentStage"/>
<local name="housekeepingStage"/>
...
<!-- Housekeeping builds -->
<ac:if>
<not><istrue value="${dependentStage}"/></not>
<ac:then>
<ac:for param="i" list="${housekeepingCount}">
<sequential>
<echo level="debug">buildId: ${@{prefixHousekeeping}@{i}.buildId}</echo>
<echo level="debug">dependsOn: ${@{prefixHousekeeping}@{i}.dependsOn}</echo>
<echo level="debug">dependsOn.done: ${@{prefixHousekeeping}@{i}.dependsOn.done}</echo>
<local name="housekeepingToken"/>
<script language="javascript">
<![CDATA[
var stringValue = project.getProperty("@{prefixHousekeeping}@{i}.dependsOn");
project.setProperty("housekeepingToken",stringValue.split(",").length);
]]>
</script>
<echo level="debug">housekeepingToken: ${housekeepingToken}</echo>
<local name="housekeepingReady"/>
<ac:if>
<length string="${@{prefixHousekeeping}@{i}.dependsOn}" when="greater" length="0"/>
<ac:then>
<condition property="housekeepingReady">
<resourcecount when="equal" count="${housekeepingToken}">
<fileset dir="@{doneDirectory}" includes="${@{prefixHousekeeping}@{i}.dependsOn.done}"/>
</resourcecount>
</condition>
</ac:then>
<ac:else>
<property name="housekeepingReady" value="true"/>
</ac:else>
</ac:if>
<echo level="debug">housekeepingReady: ${housekeepingReady}</echo>
...
</sequential>
</ac:for>
</ac:then>
</ac:if>
The Primary Element is specified to retrieve information on primary builds defined in the Build Orchestrator build. Primary builds run in dedicated build engines and are the first builds processed in an orchestrated build. The following table describes the valid Primary Element attributes:
| Primary Element Attributes | ||
| Attribute | Description | Required |
| prefix |
Specify a prefix value for the Ant properties that will be created to hold the retrieved data. Each Ant property created for a primary build entry will start with this prefix. For example, if prefix="primary" is specified, the property name for the build ID would be: primary.n.buildId where n is the array index of the primary entry.
|
Yes |
| property |
Specify the name of the property in which to return the array index string for the values returned. Each index in the string can be used to access a set of build entry values. For example, if four build entries are retrieved, this property will have a value of "1,2,3,4". Each member in this list can be substituted for the value of n above. Combining this example and the prefix example, for the first entry in the list, 1, the property name for the build ID would be: primary.1.buildId.
|
Yes |
When a Primary Element is specified and the Build Orchestrator build has primary builds defined, build definition details are returned to the Ant environment in the property arrays described in the following table:
| Primary Element Properties | ||
| Name | Value | Description |
| <prefix>.<index>.buildId | buildId | The build ID of the primary build. |
The following example is extracted from the BuildOrchestratorStart macro. The code segment listed here calls the buildOrchestrator task to retrieve primary information, creates a set of build properties, loops through the primary builds via the index property returned by the buildOrchestrator task (primaryCount), and for each primary build it calls the BuildOrchestrator.Primary macro to submit the build:
<xt:buildOrchestrator
buildResultUUID="@{buildResultUUID}"
passwordFile="@{passwordFile}"
repositoryAddress="@{repositoryAddress}"
userId="@{userId}"
verbose="@{verbose}"
>
<xt:primary prefix="@{primaryPrefix}" property="primaryCount"/>
<xt:secondary prefix="@{prefixSecondary}" property="secondaryCount"/>
</xt:buildOrchestrator>
<echo level="debug">primaryCount: ${primaryCount}</echo>
<echo level="debug">secondaryCount: ${secondaryCount}</echo>
<propertyset id="BuildOrchestratorProperties.Build">
<propertyref prefix="team.enterprise."/>
</propertyset>
<echo level="debug">Properties.Build: ${toString:BuildOrchestratorProperties.Build}</echo>
<ac:for param="i" list="${primaryCount}">
<sequential>
<propertyset id="BuildOrchestratorProperties.Entry">
<propertyref prefix="@{primaryPrefix}@{i}."/>
<mapper type="glob" from="@{primaryPrefix}@{i}.*" to="*"/>
</propertyset>
<echo level="debug">Properties.Entry: ${toString:BuildOrchestratorProperties.Entry}</echo>
<antcall target="BuildOrchestrator.Primary">
<param name="primary.activityLabel" value="@{activityLabel}"/>
<param name="primary.buildResultUUID" value="@{buildResultUUID}"/>
<param name="primary.parent" value="@{parent}"/>
<propertyset id="BuildOrchestratorProperties.Primary">
<propertyset refid="BuildOrchestratorProperties.Build"/>
<propertyset refid="BuildOrchestratorProperties.Entry"/>
</propertyset>
</antcall>
</sequential>
</ac:for>
The Secondary Element is specified to retrieve secondary builds defined in the Build Orchestrator build. Secondary builds run in the same dedicated build engines that run the primary builds, but are queued to the dedicated engines after all primary builds have been submitted. The following table describes the valid Secondary Element attributes:
| Secondary Element Attributes | ||
| Attribute | Description | Required |
| prefix |
Specify a prefix value for the Ant properties that will be created to hold the retrieved data. Each Ant property created for a secondary build entry will start with this prefix. For example, if prefix="secondary" is specified, the property name for the build ID would be: secondary.n.buildId where n is the array index of the secondary entry.
|
Yes |
| property |
Specify the name of the property in which to return the array index string for the values returned. Each index in the string can be used to access a set of build entry values. For example, if four build entries are retrieved, this property will have a value of "1,2,3,4". Each member in this list can be substituted for the value of n above. Combining this example and the prefix example, for the first entry in the list, 1, the property name for the build ID would be: secondary.1.buildId.
|
Yes |
When a Secondary Element is specified and the Build Orchestrator build has secondary builds defined, build definition details are returned to the Ant environment in the property arrays described in the following table:
| Secondary Element Properties | ||
| Name | Value | Description |
| <prefix>.<index>.buildId | buildId | The build ID of the secondary build. |
| <prefix>.<index>.dependsOn | A comma separated list of build IDs of build IDs that are prerequisites to the secondary build. | |
| <prefix>.<index>.dependsOn.done | A comma separated list of "done file" names that represent the successful completion of a prerequisite build. | |
The following example is extracted from the BuildOrchestratorStart macro. The code segment listed here calls the buildOrchestrator task to retrieve secondary information, creates a set of build properties, processes the primary builds, and then loops through the secondary builds via the index property returned by the buildOrchestrator task (secondaryCount), and for each secondary build it calls the BuildOrchestrator.Secondary macro to submit the build:
<xt:buildOrchestrator
buildResultUUID="@{buildResultUUID}"
passwordFile="@{passwordFile}"
repositoryAddress="@{repositoryAddress}"
userId="@{userId}"
verbose="@{verbose}"
>
<xt:primary prefix="@{primaryPrefix}" property="primaryCount"/>
<xt:secondary prefix="@{prefixSecondary}" property="secondaryCount"/>
</xt:buildOrchestrator>
<echo level="debug">primaryCount: ${primaryCount}</echo>
<echo level="debug">secondaryCount: ${secondaryCount}</echo>
<propertyset id="BuildOrchestratorProperties.Build">
<propertyref prefix="team.enterprise."/>
</propertyset>
<echo level="debug">Properties.Build: ${toString:BuildOrchestratorProperties.Build}</echo>
<ac:for param="i" list="${primaryCount}">
<sequential>
<propertyset id="BuildOrchestratorProperties.Entry">
<propertyref prefix="@{primaryPrefix}@{i}."/>
<mapper type="glob" from="@{primaryPrefix}@{i}.*" to="*"/>
</propertyset>
<echo level="debug">Properties.Entry: ${toString:BuildOrchestratorProperties.Entry}</echo>
<antcall target="BuildOrchestrator.Primary">
<param name="primary.activityLabel" value="@{activityLabel}"/>
<param name="primary.buildResultUUID" value="@{buildResultUUID}"/>
<param name="primary.parent" value="@{parent}"/>
<propertyset id="BuildOrchestratorProperties.Primary">
<propertyset refid="BuildOrchestratorProperties.Build"/>
<propertyset refid="BuildOrchestratorProperties.Entry"/>
</propertyset>
</antcall>
</sequential>
</ac:for>
<ac:for param="i" list="${secondaryCount}">
<sequential>
<propertyset id="BuildOrchestratorProperties.Entry">
<propertyref prefix="@{prefixSecondary}@{i}."/>
<mapper type="glob" from="@{prefixSecondary}@{i}.*" to="*"/>
</propertyset>
<echo level="debug">Properties.Entry: ${toString:BuildOrchestratorProperties.Entry}</echo>
<antcall target="BuildOrchestrator.Secondary">
<param name="secondary.activityLabel" value="@{activityLabel}"/>
<param name="secondary.buildResultUUID" value="@{buildResultUUID}"/>
<param name="secondary.parent" value="@{parent}"/>
<propertyset id="BuildOrchestratorProperties.Secondary">
<propertyset refid="BuildOrchestratorProperties.Build"/>
<propertyset refid="BuildOrchestratorProperties.Entry"/>
</propertyset>
</antcall>
</sequential>
</ac:for>
When specifying the buildResultUuid attribute be sure to specify the build result UUID of a Build Orchestrator build result. The UUID of build results from orchestrated builds - Dependent, DependsOn, Housekeeping, Primary, and Secondary builds - will not have a UUID that qualifies. Only the result from a Build Orchestrator build, a build with a Build Orchestrator configuration element, qualifies. Orchestrated builds must be passed the UUID of the Build Orchestrator build result to use this attribute.