The SCM integrations enable AnthillPro to check out code, access the changelog, and label the repository (where supported). To do this, AnthillPro is first configured with your repository type at the System level, and then each workflow is associated with the source to be build.
The SCM integrations are implemented as job steps for a build job. Once you have completed source configuration, you can use the Job Wizard to automatically add steps to your build job -- this ensures that AnthillPro will consistently checkout and build the correct code.
Each SCM integration typically performs the following for any repository:
Checkout. This step enables you to define which version of code to check out from the SCM. For example, you can configure this step to checkout the latest source code; or perform a checkout based on a branch, label, date, etc. (depending on what your SCM supports).
Get-changelog. The retrieved changelog is usually based on the changes made since the previous build. This step enables AnthillPro to extract data from the SCM and then store it in the AnthillPro data warehouse. Since AnthillPro stores the changelogs, it can parse the data, allowing you to override the default behavior. For example, you can select a starting point for the changelog based on criteria such as the latest production build.
Label. AnthillPro can also apply a label to the source code used in the build (e.g., snapshot, baseline). This unique identifier for a build can be used to recreate a build if necessary.
SCM-specific commands. For most repository types, AnthillPro can also perform tasks only supported by that particular SCM.
The first step in using an AccuRev repository with AnthillPro is to create a repository configuration by following the Repositories link on the System page. The configuration will allow basic information regarding AccuRev to be reused by several projects. Once configured, the repository will be listed on the Repositories main page.
In AnthillPro, there are two ways to use an AccuRev repository:
Pooling streams. AnthillPro creates and manages a pool of AccuRev streams to be used for the project, and does not require creation of AccuRev workspaces. Any streams included in the pool are automatically locked and should not be edited (locked streams may be viewed at System > Lockable Resources for those with Administrative permissions). This option is simpler than the alternative, and requires less configuration and management. See AccuRev Source Configuration with Pooling Streams.
Non-pooling streams. AnthillPro does not create and maintain a pool of children streams for the project. Management of streams and workspaces must be done through AccuRev. See AccuRev Source Configuration with Non-pooling Streams.
Once the main repository has been identified, your projects can then use the AccuRev repository during workflow source configuration. During project creation, the workflow is associated with a specific AccuRev repository.
| AnthillPro also provides an integration with AccuWork. The integration enables AnthillPro to utilize AccuWork's bridge between third-party issue trackers (such as Bugzilla and JIRA) and AccuRev to publish the generated issue report to AnthillPro Build Life. Once the report is published to AnthillPro, it is then be made available on the Build Life Issues tab. See AccuWork. |
AccuRev must already be installed. See AccuRev documentation.
You must have administrative permissions. See Manage Security.
The AccuRev command path must be available to complete the configuration.
AccuRev Login. For versions 4.5.1 and above, the new AccuRev authentication scheme now requires a manual login (usually daily) in order for an AnthillPro agent to access the repository. To override this behavior, you can automate login by using the
-noption with the AccuRev login command. This will cache the credentials so that AccuRev no longer asks for a password for that account. If you want to automate login for the AnthillPro agent(s):Login to AccuRev with the account that the AnthillPro agent uses to access the repository.
Run the AccuRev login command with the
-nflag:accurev login -n.If you have AnthillPro agents that login to AccuRev as different users, you will need to repeat this operation for those agents as well.
Go to System > Repositories from the Project Support menu.
On the Repositories page, click the Create New button.
Select AccuRev from the drop-down menu and click Set.
Configure repository:
Name the repository. This is the name AnthillPro will use to identify this repository. This name does not correspond to the actual repository, and is simply an identifying label used by the AnthillPro system.
Description. Give an optional description.
Command Path. Provide the location of the AccuRev executable if it is not in the system path.
Pool Streams. If not using an AnthillPro pool of streams, do not check the box and proceed to Item 5 (see AccuRev Source Configuration with Non-pooling Streams).
To use an AnthillPro-created pool of AccuRev streams across projects using this repository, check the box (see AccuRev Source Configuration with Pooling Streams).
Max Number in Pool. Give the maximum number of AccuRev streams AnthillPro will create in the pool (if using the Pool Streams option).
Click Set.
Select the Security tab and click the Edit button. Determine permissions, click Save, and then click Done.
Click Done.
Once the main AccuRev repository is identified (see Set Up AccuRev Repository), configure the specific repository a workflow uses. During project creation, the originating workflow is first associated with the AccuRev repository. Once this is done, the Source Configuration page will automatically pop up. (However, if you choose not to configure the project source at initial creation, you can return to it by selecting the Configure, or Edit Source, link under the Source Config menu on the Workflow Main page.)
Once AccuRev is set up with AnthillPro (see Set Up AccuRev Repository), create a project.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
Repository. Select the appropriate AccuRev repository from the drop-down menu. All AccuRev repositories configured with AnthillPro (see Set Up AccuRev Repository) will appear in the drop-down menu. Make sure to select the correct repository for this project.
Working Directory Script. Select the Working Directory Script from the drop-down menu. The working directory is the location where the agent is going to run its commands. For example, if the working directory is
C:\projects\Project_A\every command AnthillPro issues will be from that specific directory.If no Working Directory Script is configured in the job, the script selected here will be used. See Working Directory Scripts.
Directory Offset. Give the relative directory path from the working directory where this stream should be pulled. Leave blank for the root of the working directory.
This option is especially useful when using multiple Sources (see Add Additional Source with Pooling Streams).
Stream Name. Provide the name of the parent stream to back the pooled stream with. This field accepts small scripts for including properties, etc.
Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File paths to exclude from changelog. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.
Click Save.
If adding additional sources to the workflow is necessary, set up is similar to that of the initial source configuration (see AccuRev Source Configuration with Pooling Streams). When adding additional sources, it is advisable (though not required) to create a new directory offset for each additional source.
Once an additional source has been added to the workflow, it will appear on the workflow Main tab under the Source Config menu, and may be edited or deleted using the icons under the Actions menu.
To add an additional source to an existing workflow:
Go to Administration and select the workflow that an additional source is to be added to.
On the workflow Main page, select the Add Additional Source link under the Source Config menu.
Configure source:
Directory Offset. Give the relative directory path from the working directory where this stream should be pulled. Leave blank for the root of the working directory. For example, enter Test to create the offset named "Test".
This option is especially useful when using multiple Sources. Each source may use a different offset, making it easier to pull different streams down at the same time.
Stream Name. Provide the name of the parent stream to back the pooled stream with. This field accepts small scripts for including properties, etc.
Click Save.
Once the main AccuRev repository is identified (see Set Up AccuRev Repository), configure the specific repository a workflow uses. During project creation, the originating workflow is first associated with the AccuRev repository. Once this is done, the Source Configuration page will automatically pop up. (However, if you choose not to configure the project source at initial creation, you can return to it by selecting the Configure, or Edit Source, link under the Source Config menu on the Workflow Main page.)
Once AccuRev is set up with AnthillPro (see Set Up AccuRev Repository), create a project.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
Repository. Select the appropriate AccuRev repository from the drop-down menu. All AccuRev repositories configured with AnthillPro (see Set Up AccuRev Repository) will appear in the drop-down menu. Make sure to select the correct repository for this project.
Working Directory Script. Select the Working Directory Script from the drop-down menu. The working directory is the location where the agent is going to run its commands. For example, if the working directory is
C:\projects\Project_A\every command AnthillPro issues will be from that specific directory.If no Working Directory Script is configured in the job, the script selected here will be used. See Working Directory Scripts.
Directory Offset. Give the relative directory path from the working directory where this stream should be pulled. Leave blank for the root of the working directory. For example, enter Test to create the offset named "Test".
This option is especially useful when using multiple sources. Each source may use a different offset, making it easier to pull different streams down at the same time. See Add Additional Source with Non-pooling Streams.
Stream Name. Provide the name of the stream to build from. This field accepts small scripts for including properties, etc. This may not be a pass-through stream. Only use a child stream off of the development stream where the changes are committed.
Workspace Name. Give the name of the AccuRev workspace to use. This field accepts small scripts for including properties, etc. Do not include the _user-name at the end of the workspace name, this will be determined by the credentials in the AccuRev Repository Configuration.
History Stream Name. Give the name of the AccuRev parent stream from which the history of changes will be collected. Use the Stream Name option only if this stream is different from the stream name listed above (see Stream Name). This option is helpful when labeling a history stream, to ensure that the proper snapshot is used for labeling. See Label On History Stream below.
Disable Time Locking. Check the box to override the automatic time lock that AnthillPro sets on the backing stream. Note that without the time lock, there is no guarantee that a build can be reproduced.
Label On History Stream. Check the box create a snapshot of the parent/history stream. If a child stream as used as the backing stream, any labelling of that child stream may produce inconsistent results. The only way to ensure proper labeling results is to create a snapshot on the parent/history stream.
When using this option, make sure that the AccuRev parent stream is defined in the History Stream Name. See History Stream Name above.
Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File paths to exclude from changelog. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.
Click Save.
If adding additional sources to the workflow is necessary, set up is similar to that of the initial source configuration (see AccuRev Source Configuration with Non-pooling Streams). When adding additional sources, it is advisable (though not required) to create a new directory offset for each additional source.
Once an additional source has been added to the workflow, it will appear on the workflow Main tab under the Source Config menu, and may be edited or deleted using the icons under the Actions menu.
To add an additional source to an existing workflow:
Go to Administration and select the workflow that an additional source is to be added to.
On the workflow Main page, select the Add Additional Source link under the Source Config menu.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
Directory Offset. Give the relative directory path from the working directory where this stream should be pulled. Leave blank for the root of the working directory. For example, enter Test to create the offset named "Test".
This option is especially useful when using multiple sources. Each source may use a different offset, making it easier to pull different streams down at the same time.
Stream Name. Provide the name of the stream to build from. This field accepts small scripts for including properties, etc. This may not be a pass-through stream. Only use a child stream off of the development stream where the changes are committed.
Workspace Name. Give the name of the AccuRev workspace to use. This field accepts small scripts for including properties, etc. Do not include the _user-name at the end of the workspace name, this will be determined by the credentials in the AccuRev Repository Configuration.
History Stream Name. Give the name of the AccuRev parent stream from which the history of changes will be collected. Use the Stream Name option only if this stream is different from the stream name listed above (see Stream Name). This option is helpful when labeling a history stream, to ensure that the proper snapshot is used for labeling. See Label On History Stream below.
Disable Time Locking. Check the box to override the automatic time lock that AnthillPro sets on the backing stream. Note that without the time lock, there is no guarantee that a build can be reproduced.
Label On History Stream. Check the box create a snapshot of the parent/history stream. If a child stream as used as the backing stream, any labelling of that child stream may produce inconsistent results. The only way to ensure proper labeling results is to create a snapshot on the parent/history stream.
When using this option, make sure that the AccuRev parent stream is defined in the History Stream Name. See History Stream Name above.
Click Save.
AnthillPro provides a number of integrations with ClearCase, each based on different ClearCase usage scenarios. Which integration you use will depend on your particular needs and your organizational/team ClearCase set up. Generally, the integrations fall into one of two categories:
ClearCase Base. AnthillPro supports both dynamic and snapshot views. In addition to the legacy integrations (ClearCase Base Dynamic View and ClearCase Base Snapshot View), AnthillPro also offers newer plugin integrations (see ClearCase Base Dynamic [Plugin] and ClearCase Base Snapshot [Plugin]). While the plugin versions are similar to the legacy integrations, they do offer additional functionality. Notably, the ability to add multiple source configurations to an originating (build) workflow and additional configuration options.
ClearCase UCM. If you use UCM, you can configure the ClearCase UCM Dynamic View and/or the ClearCase UCM Snapshot View integration. It's worth noting that a single originating (build) workflow can have only one view-type set up during source configuration. If you use multiple views within the same project, you will need to configure a separate workflow for each view. UCM versions of ClearCase are not supported by the plugin integrations.
In addition, AnthillPro also provides an integration with ClearQuest that can be used in conjunction with any of the ClearCase integrations.
The first step in using a ClearCase Base Dynamic Plugin repository with AnthillPro is to configure it by following the Repositories link on the System page. The configuration will allow basic information regarding ClearCase to be reused by several project workflows. Once configured, the repository will be listed on the Repositories main page.
Once the main repository has been identified, your projects can then use the ClearCase repository. During project creation, associate the workflow with a specific ClearCase repository and specify the Load Rules. See ClearCase Base Dynamic (Plugin) Source Configuration.
See also ClearQuest.
ClearCase must already be installed. See ClearCase documentation.
You must have administrative permissions. See Manage Security.
The cleartool executable and the Load Rules must be available to complete the configuration.
If you are not familiar with ClearCase, it is recommended to consult with your ClearCase administrator while configuring the integration.
The integration is available as an AnthillPro plugin for version 3.7 and above. For some AnthillPro 3.7 versions, you will need to download the integration (called ClearCase Base Dynamic Plugin) from Supportal and then upload it to your server. Once uploaded, ensure the Plugin is active. From there, configure the repository. The information you give here is system wide, and will be used by your ClearCase projects. If you have multiple ClearCase repositories, you will need to configure the integration for each one ... ensuring each has a unique name.
If not already done so, ensure the ClearCase Base Dynamic Plugin has been uploaded to the server. See Using AnthillPro Plugins.
Go to System > Repositories from the Project Support menu.
On the Repositories page, click the Create New button.
Select ClearCase Base Dynamic from the drop-down menu and click Set.
Configure repository:
Name the repository. This is the name AnthillPro will use to identify this repository. This name does not correspond to the actual repository, and is simply an identifying label used by the AnthillPro system. If you are configuring multiple repositories, ensure the name you give is unique. This name will be used as part of source configuration.
Description. Give an optional description.
Command Path. Provide the location of the ClearCase executable if it is not in the system path on the machine that will run the build.
Click Set then Done.
Once the main ClearCase repository is identified (see Set Up ClearCase Base Dynamic (Plugin) Repository), configure the specific repository a workflow uses. During project creation, the originating workflow is first associated with the ClearCase repository. Once this is done, the Source Configuration page will automatically pop up. (However, if you choose not to configure the project source at initial creation, you can return to it by selecting the Configure, or Edit Source, link under the Source Config menu on the Workflow Main page.)
In addition, the plugin integration allows you to add multiple source configurations to the originating (build) workflow. It's worth noting that this feature also allows you to configure multiple views (Snapshot and Dynamic) for a build workflow as well as different project locations. How, when and why you use this feature depends on your individual processes. Generally, you will only need one source configuration per build workflow.
Once ClearCase is set up with AnthillPro (see Set Up ClearCase Base Dynamic (Plugin) Repository), create a project.
When prompted, select the integration you configured in the previous section. If necessary, you can exit the configuration process and return to it later.
Go to the originating workflow that was created as part of the project creation process (if you chose not to continue in the previous step) and configure the source on the workflow:
Working Directory Script. Select the Working Directory to be used for this source configuration. The working directory is where the checked-out source will be placed in and where the build occurs. Under most circumstances, the Default Project Working Directory should suffice. For more Working Directory Scripts, see the Dev Kit (via the tools link in the upper right-hand corner of the UI).
Name. Give a name for this source configuration. The name given here is used to identify the configuration. This can come in handy if you plan on adding multiple configurations to the same workflow.
View Storage Directory. Give the location of the view on the local machine. This is the volume that views are mounted on (e.g.,. M:\ ) On Windows this will usually be of the form
//host/share/view_storage.Load Rules. Give the Load Rules configured in the View Configuration Specifications to tell AnthillPro what projects, branches, and labels to use. AnthillPro requires the specs to be in the form
<vob-name><path>:<branch>:<label>. Each Load Rule must be input on a separate line.If the View Load Rules are configured with the value
BaseModeTest:Anthill-Example::, then they are input asvob-name BaseModeTest(following the form<vob-name><path>:<branch>:<label>) in the Load Rules field. Note that the Source Config deals with thevob-name BaseModeTestand that the project is located in theAnthill-Exampledirectory under our VOB.To build from the branch named test, the Load Rule line would be
BaseModeTest:Anthill-Example:test: (all builds performed on the test branch).To perform a build on label 1.0.3 the Load Rule would be
BaseModeTest:Anthill-Example::1.0.3.To build from label 1.0.3 of branch test the Load Rule would be
BaseModeTest:Anthill-Example:test:1.0.3.Example Load Rule Configuration
For the load rules below, AnthillPro needs to know the path and optional branch and label the configspec is checking out in order to find the changes and then apply any needed labels. For example, the branch and label would come from lines starting with element, paths come from the lines starting with load, etc.
element* CHECKEDOUT element/elementName/... .../elementNameApplication/LATEST element/elementName/... .../iter2_elementNameApplication/LATEST -mkbranch elementNameApplication element/mmisPortal/... /main/LATEST -mkbranch iter2_portal element* .../element_customization/LATEST element* .../main/LATEST load /elementNamePortal load /elementNameCommon load /elementNameFramework
For example, if you look at the first line in the load rules:
element/elementName/... .../elementNameApplication/LATESTmeans that for path
/elementNameyou need to get the code from theelementNameApplicationbranch (LATESTis the default label so you can ignore it when configuring AnthillPro). This translates in the following load rule (using the patternVOB:/path_in_vob:branch:label):elementName:/:elementNameApplication:In the same manner, the second line translates into
elementName:/:iter2_elementNameApplication:However, the
-mkbranchin the line is ignored when configuring AnthillPro since-mkbranchsays it's not about getting code but committing code back.For the line
element* .../element_customization/LATESTmeans that for every load rule we need to get the code from theelement_customizationbranch. This requires one load rule be configured in AnthillPro per load rule in ClearCase. Thus, you would have something like:elementName:/:element_customization:elementNameCommon:/:element_customization:elementNameFramework:/:element_customization:Note that
element* .../main/LATESTalso needs to be addressed. In the example, you will need to get code from the main branch. This should look something like:elementNamePortal:/::elementNameCommon:/::elementNameFramework:/::VOB Tag Root. Only use this setting if you are running cross-platform builds including Windows and UNIX and using multi-component vobs. When specifying the vob tag root do not use any starting or trailing slashes. The value is usually vobs.
Create global labels. Check the box to create global labels. You can also specify in which VOBs those labels will be created (see below). If you do not specify any VOBs (below), the Load Rules will be used to determine all the VOBs that are used, and labels will be created in those VOBs.
Create label in VOBs. Please list the names of the VOBs (one per line) where the global labels should be created. If you are not creating global labels (option above is not selected) you can list all the VOBs used in your config spec or leave the field empty and the Load Rules will be used to determine where the labels need to be created.
Delete view-private files during cleanup. Select here if you would like AnthillPro to detect and delete any view-private files in the local view. This is highly recommended unless your build script handles cleanup of the view. Only the paths specified in the Load Rules above will be checked for view-private files.
No-checkout. Check the box to pass the
-ncoflag to the quietperiod lshistory call. Typically, this option is used when you do not want non-checkouts in the history to trigger builds.Lock Objects. Please list the names of the objects (one per line) that you would like locked/unlocked during the build process. Use the following format:
type:Name@VOB(or refer to the lock/unlock ClearCase command reference for more details). Be advised that if you leave this field empty, there is nothing to prevent an update of the dynamic view while there is a build in progress.Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File Filters. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.Repository. Select the repository configured in the previous section. If more than one configuration is present, ensure the correct repository configuration is chosen.
Click Save.
The first step in using a ClearCase Base Dynamic View repository with AnthillPro is to configure it by following the Repositories link on the System page. The configuration will allow basic information regarding ClearCase to be reused by several project workflows. Once configured, the repository will be listed on the Repositories main page.
Once the main repository has been identified, your projects can then use the ClearCase repository. During project creation, associate the workflow with a specific ClearCase repository and determine the mode, view, and specify the Load Rules. See ClearCase Base Dynamic View Source Configuration.
See also ClearQuest.
ClearCase must already be installed. See ClearCase documentation.
You must have administrative permissions. See Manage Security.
The cleartool executable and the Load Rules must be available to complete the configuration.
If you are not familiar with ClearCase, it is recommended to consult with your ClearCase administrator while configuring the integration.
Go to System > Repositories from the Project Support menu.
On the Repositories page, click the Create New button.
Select ClearCase from the drop-down menu and click Set.
Configure repository:
Name the repository. This is the name AnthillPro will use to identify this repository. This name does not correspond to the actual repository, and is simply an identifying label used by the AnthillPro system.
Description. Give an optional description.
Command Path. Provide the location of the ClearCase executable if it is not in the system path.
Click Set.
Select the Security tab and click the Edit button. Determine permissions, click Save, and then click Done.
Click Done.
Once the main ClearCase repository is identified (see Set Up ClearCase Base Dynamic View Repository), configure the specific repository a workflow uses. During project creation, the originating workflow is first associated with the ClearCase repository. Once this is done, the Source Configuration page will automatically pop up. (However, if you choose not to configure the project source at initial creation, you can return to it by selecting the Configure, or Edit Source, link under the Source Config menu on the Workflow Main page.)
Once ClearCase is set up with AnthillPro (see Set Up ClearCase Base Dynamic View Repository), create a project.
Select the Mode and View Type once ClearCase has been selected as the repository type.
Mode. Choose Base.
View Type. Choose Use Dynamic.
Click Select.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
View Storage Directory. Give the location of the view on the local machine. On Windows this will be of the form
//host/share/view_storage.Load Rules. Give the Load Rules configured in the View Configuration Specifications to tell AnthillPro what projects, branches, and labels to use. AnthillPro requires the specs to be in the form
<vob-name><path>:<branch>:<label>. Each Load Rule must be input on a separate line.If the View Load Rules are configured with the value
BaseModeTest:Anthill-Example::, then they are input asvob-name BaseModeTest(following the form<vob-name><path>:<branch>:<label>) in the Load Rules field. Note that the Source Config deals with thevob-name BaseModeTestand that the project is located in theAnthill-Exampledirectory under our VOB.To build from the branch named test, the Load Rule line would be
BaseModeTest:Anthill-Example:test: (all builds performed on the test branch).To perform a build on label 1.0.3 the Load Rule would be
BaseModeTest:Anthill-Example::1.0.3.To build from label 1.0.3 of branch test the Load Rule would be
BaseModeTest:Anthill-Example:test:1.0.3.Example Load Rule Configuration
For the load rules below, AnthillPro needs to know the path and optional branch and label the configspec is checking out in order to find the changes and then apply any needed labels. For example, the branch and label would come from lines starting with element, paths come from the lines starting with load, etc.
element* CHECKEDOUT element/elementName/... .../elementNameApplication/LATEST element/elementName/... .../iter2_elementNameApplication/LATEST -mkbranch elementNameApplication element/mmisPortal/... /main/LATEST -mkbranch iter2_portal element* .../element_customization/LATEST element* .../main/LATEST load /elementNamePortal load /elementNameCommon load /elementNameFramework
For example, if you look at the first line in the load rules:
element/elementName/... .../elementNameApplication/LATESTmeans that for path
/elementNameyou need to get the code from theelementNameApplicationbranch (LATESTis the default label so you can ignore it when configuring AnthillPro). This translates in the following load rule (using the patternVOB:/path_in_vob:branch:label):elementName:/:elementNameApplication:In the same manner, the second line translates into
elementName:/:iter2_elementNameApplication:However, the
-mkbranchin the line is ignored when configuring AnthillPro since-mkbranchsays it's not about getting code but committing code back.For the line
element* .../element_customization/LATESTmeans that for every load rule we need to get the code from theelement_customizationbranch. This requires one load rule be configured in AnthillPro per load rule in ClearCase. Thus, you would have something like:elementName:/:element_customization:elementNameCommon:/:element_customization:elementNameFramework:/:element_customization:Note that
element* .../main/LATESTalso needs to be addressed. In the example, you will need to get code from the main branch. This should look something like:elementNamePortal:/::elementNameCommon:/::elementNameFramework:/::Create global labels. Check the box to create global labels. You can also specify in which VOBs those labels (see below). If you do not specify any VOBs (below), the Load Rules will be used to determine all the VOBs that are used, and labels will be created in those VOBs.
Create labels in VOBs. Please list the names of the VOBs (one per line) where the global labels should be created. If you are not creating global labels (option above is not selected) you can list all the VOBs used in your config spec or leave the field empty and the Load Rules will be used to determine where the labels need to be created.
Delete view-private files during cleanup. Select here if you would like AnthillPro to detect and delete any view-private files in the local view. This is highly recommended unless your build script handles cleanup of the view. Only the paths specified in the Load Rules above will be checked for view-private files.
Lock Objects. Please list the names of the objects (one per line) that you would like locked/unlocked during the build process. Use the following format:
type:Name@VOB(or refer to the lock/unlock ClearCase command reference for more details). Be advised that if you leave this field empty, there is nothing to prevent an update of the dynamic view while there is a build in progress.Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File paths to exclude from changelog. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.
Click Save.
The first step in using a ClearCase Base Snapshot Plugin repository with AnthillPro is to configure it by following the Repositories link on the System page. The configuration will allow basic information regarding ClearCase to be reused by several project workflows. Once configured, the repository will be listed on the Repositories main page.
Once the main repository has been identified, your projects can then use the ClearCase repository. During project creation, associate the workflow with a specific ClearCase repository and specify the ChangeLog Rules. See ClearCase Base Snapshot (Plugin) Source Configuration.
During source configuration, you must select a View Strategy. The strategy will determine how AnthillPro interacts with existing views and determine when AnthillPro should create a new view. Select a strategy that either (a.) creates a new view with every build; (b.) create a new view if and only if a view does not exist; or (c.) does not create a new view and uses an existing view. Only one view may be configured on an individual workflow; however, if a project has multiple workflows, a separate View Strategy may be used for each workflow.
See also ClearQuest.
ClearCase must already be installed. See ClearCase documentation.
You must have administrative permissions. See Manage Security.
The cleartool executable and the ChangeLog Rules must be available to complete the configuration.
If you are not familiar with ClearCase, it is recommended to consult with your ClearCase administrator while configuring the integration.
The integration is available as an AnthillPro plugin for version 3.7 and above. For some AnthillPro 3.7 versions, you will need to download the integration (called ClearCase Base Snapshot Plugin) from Supportal and then upload it to your server. Once uploaded, ensure the Plugin is active. From there, configure the repository. The information you give here is system wide, and will be used by your ClearCase projects. If you have multiple ClearCase repositories, you will need to configure the integration for each one ... ensuring each has a unique name.
If not already done so, ensure the ClearCase Base Snapshot Plugin has been uploaded to the server. See Using AnthillPro Plugins.
Go to System > Repositories from the Project Support menu.
On the Repositories page, click the Create New button.
Select ClearCase Base Snapshot from the drop-down menu and click Set.
Configure repository:
Name the repository. This is the name AnthillPro will use to identify this repository. This name does not correspond to the actual repository, and is simply an identifying label used by the AnthillPro system. If you are configuring multiple repositories, ensure the name you give is unique. This name will be used as part of source configuration.
Description. Give an optional description.
Command Path. Provide the location of the ClearCase executable if it is not in the system path on the machine that will run the build.
Click Set then Done.
Once the main ClearCase repository is identified (see Set Up ClearCase Base Snapshot (Plugin) Repository), configure the specific repository a workflow uses. During project creation, the originating workflow is first associated with the ClearCase repository. Once this is done, the Source Configuration page will automatically pop up. (However, if you choose not to configure the project source at initial creation, you can return to it by selecting the Configure, or Edit Source, link under the Source Config menu on the Workflow Main page.)
During configuration, you will need to ensure that the appropriate fields are configured for the view strategy you select. Any fields identified as "required for all views" or "optional for all views" are used regardless of the view strategy you use. Any filed that is view-specific is identified as such.
In addition, the plugin integration allows you to add multiple source configurations to the originating (build) workflow. It's worth noting that this feature also allows you to configure multiple views (Snapshot and Dynamic) for a build workflow as well as different project locations. How, when and why you use this feature depends on your individual processes. Generally, you will only need one source configuration per build workflow.
Once ClearCase is set up with AnthillPro (see Set Up ClearCase Base Snapshot (Plugin) Repository), create a project.
When prompted, select the integration you configured in the previous section. If necessary, you can exit the configuration process and return to it later.
Go to the originating workflow that was created as part of the project creation process (if you chose not to continue in the previous step) and configure the source on the workflow:
Name (required for all views). Give a name for this source configuration. The name given here is used to identify the configuration. This can come in handy if you plan on adding multiple configurations to the same workflow.
ChangeLog Rules (required for all views). Give the ChangeLog Rules configured in the View Configuration Specifications to tell AnthillPro what projects, branches, and labels to use. AnthillPro requires the specs to be in the form
<vob-name><path>:<branch>:<label>. Each Rule must be input on a separate line.If the Rules are configured with the value
BaseModeTest:Anthill-Example::, then they are input asvob-name BaseModeTest(following the form<vob-name><path>:<branch>:<label>) in the Rules field. Note that the Source Config deals with thevob-name BaseModeTestand that the project is located in theAnthill-Exampledirectory under our VOB.To build from the branch named test, the Rule would be
BaseModeTest:Anthill-Example:test: (all builds performed on the test branch).To perform a build on label 1.0.3 the Rule would be
BaseModeTest:Anthill-Example::1.0.3.To build from label 1.0.3 of the branch named test, the Rule would be
BaseModeTest:Anthill-Example:test:1.0.3.Example ChangeLog Rule Configuration
For the Rules below, AnthillPro needs to know the path and optional branch and label the configspec is checking out in order to find the changes and then apply any needed labels. For example, the branch and label would come from lines starting with element, paths come from the lines starting with load, etc.
element* CHECKEDOUT element/elementName/... .../elementNameApplication/LATEST element/elementName/... .../iter2_elementNameApplication/LATEST -mkbranch elementNameApplication element/mmisPortal/... /main/LATEST -mkbranch iter2_portal element* .../element_customization/LATEST element* .../main/LATEST load /elementNamePortal load /elementNameCommon load /elementNameFramework
For example, if you look at the first line in the Rules:
element/elementName/... .../elementNameApplication/LATESTmeans that for path
/elementNameyou need to get the code from theelementNameApplicationbranch (LATESTis the default label so you can ignore it when configuring AnthillPro). This translates in the following Rule (using the patternVOB:/path_in_vob:branch:label):elementName:/:elementNameApplication:In the same manner, the second line translates into
elementName:/:iter2_elementNameApplication:However, the
-mkbranchin the line is ignored when configuring AnthillPro since-mkbranchsays it's not about getting code but committing code back.For the line
element* .../element_customization/LATESTmeans that for every Rule we need to get the code from theelement_customizationbranch. This requires one Rule be configured in AnthillPro per Rule in ClearCase. Thus, you would have something like:elementName:/:element_customization:elementNameCommon:/:element_customization:elementNameFramework:/:element_customization:Note that
element* .../main/LATESTalso needs to be addressed. In the example, you will need to get code from the main branch. This should look something like:elementNamePortal:/::elementNameCommon:/::elementNameFramework:/::VOB Tag Root (optional for all views). Only use this setting if you are running cross-platform builds including Windows and UNIX and using multi-component vobs. When specifying the vob tag root do not use any starting or trailing slashes. The value is usually vobs.
Create global labels (optional for all views). Check the box to create global labels. You can also specify in which VOBs those labels will be created (see below). If you do not specify any VOBs (below), the Load Rules will be used to determine all the VOBs that are used, and the labels will be created in those VOBs.
Create labels in VOBs (optional for all views). Please list the names of the VOBs (one per line) where the global labels should be created. If you are not creating global labels (option above is not selected) you can list all the VOBs used in your config spec or leave the field empty, and the Load Rules will be used to determine where the labels need to be created.
Delete view-private files during cleanup (optional for Already Exists and Doesn't Exist views). Select here if you would like AnthillPro to detect and delete any view-private files in the local view. This is highly recommended unless your build script handles cleanup of the view. Only the paths specified in the Rules above will be checked for view-private files.
Host name (optional for Everytime and Doesn't Exist views). Provides the value for the
-hostparameter to be used in themkviewcommand. Use this filed only if the view and storage are in different locations.Global storage path
[gpath] (optional for Everytime and Doesn't Exist views). Provides the value for the-gpathparameter to be used in themkviewcommand. Use this filed only if the view and storage are in different locations.Host storage path
[hpath] (optional for Everytime and Doesn't Exist views). Provides the value for the-hpathparameter to be used in themkviewcommand. Use this filed only if the view and storage are in different locations.View Strategy. Select a view strategy. Which fields you configure depends on the view you select:
Everytime. Create a new view every time we build. If this option is chosen, AnthillPro will check for an existing snapshot view and remove it before creating a new view with every build. This option will ensure that the view always represents the state of the current build.
Doesn't Exist. Create a new view only if one does not exist already. AnthillPro will check for an existing snapshot view. If one is found, a new view will not be created. If no existing view is found, AnthillPro will create a new one. This option allows you to use an existing view; however, that view may not represent the state of the latest build.
Already Exists. The view already exists and will be used every time. AnthillPro will not create a new view and use the existing view. This option will always use the view that previously exists. If no view exists, one must be created prior to using this option.
View Location (required for all views). If strategy is Already Exists, the location of the view on the local machine. Otherwise, The location of the view storage directory on the ClearCase server where the views are stored. For Windows operating systems this should always be a UNC path of the form
//host/share/view_location.View Name (required for all views). Give the name to use for the view when creating and deleting. Ensure that the name given here is unique. Note the agent that will be running the job also needs to have a unique view name. To accomplish this, scripts can be used. For example, using the following script will ensure the name is unique (you can copy the script into the text box as is):
${bsh:ProjectLookup.getCurrent().getName()}_view_${bsh:AgentHelper.getCurrent().getName()}Config Spec (optional for Everytime and Doesn't Exist views). Provide the config spec to be used for the new view. Please replace any labels used in the config spec with a token.
For example:
/main/LATESTshould become/main/${LATEST}and/main/test/1.0.3should become/main/test/${1.0.3}.Place a time token after any element rules that do not load from a particular label: element
* /main/LATESTshould become element* /main/LATEST $[time.token]and element* /main/test/LATESTshould become element* /main/test/LATEST $[time.token].Do not assign the element
* /main/test/1.0.3a time token.Check New Config Spec (optional for Everytime and Doesn't Exist views). Select here if you want to compare the newly set configspec against the user-specified configspec. This option allows you to determine success based on the new configspec set on the view rather than the outcome of the setcs command.
Label to check out from (optional for Everytime and Doesn't Exist views). Give the label to check out source from (if any). Leave blank if not checking out via a label.
Tmode (optional for Everytime and Doesn't Exist views). Select the correct text mode to use -- the standard ClearCase options are available. See About text modes for view at the IBM Software information center for more.
Use VOB Time (optional for Everytime and Doesn't Exist views). Check to box if you want to use the time stamp from when the file was checked in. If you leave this blank, the time the file was checked out will be used.
Use Tags (optional for all views). Select here if you want your view to be globally created. Having this option checked can cause problems with creating and dropping snapshots if you wish to have the same snapshot on multiple agents.
No-checkout (optional for all views). Check the box to pass the
-ncoflag to the quietperiod lshistory call. Typically, this option is used when you do not want non-checkouts in the history to trigger builds.Users to exclude from changelog (optional for all views). To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File Filters (optional for all views). If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.Repository (required for all views). Select the repository configured in the previous section. If more than one configuration is present, ensure the correct repository configuration is chosen.
Click Save.
The first step in using a ClearCase Base Snapshot View repository with AnthillPro is to configure it by following the Repositories link on the System page. The configuration will allow basic information regarding ClearCase to be reused by several project workflows. Once configured, the repository will be listed on the Repositories main page.
Once the main repository has been identified, your projects can then use the ClearCase repository. During project creation, associate the workflow with a specific ClearCase repository and determine the mode, view, and specify the Load Rules. See ClearCase Base Snapshot View Source Configuration.
During source configuration, you must select a View Strategy. The strategy will determine how AnthillPro interacts with existing views and determine when AnthillPro should create a new view. Select a strategy that either (a.) creates a new view with every build; (b.) create a new view if and only if a view does not exist; or (c.) does not create a new view and uses an existing view. Only one view may be configured on an individual workflow; however, if a project has multiple workflows, a separate View Strategy may be used for each workflow. See View Strategy.
See also ClearQuest.
ClearCase must already be installed. See ClearCase documentation.
You must have administrative permissions. See Manage Security.
The cleartool executable and the Load Rules must be available to complete the configuration.
If you are not familiar with ClearCase, it is recommended to consult with your ClearCase administrator while configuring the integration.
Go to System > Repositories from the Project Support menu.
On the Repositories page, click the Create New button.
Select ClearCase from the drop-down menu and click Set.
Configure repository:
Name the repository. This is the name AnthillPro will use to identify this repository. This name does not correspond to the actual repository, and is simply an identifying label used by the AnthillPro system.
Description. Give an optional description.
Command Path. Provide the location of the ClearCase executable if it is not in the system path.
Click Set.
Select the Security tab and click the Edit button. Determine permissions, click Save, and then click Done.
Click Done.
Once the main ClearCase repository is identified (see Set Up ClearCase Base Snapshot View Repository), configure the specific repository a workflow uses. During project creation, the originating workflow is first associated with the ClearCase repository. Once this is done, the Source Configuration page will automatically pop up. (However, if you choose not to configure the project source at initial creation, you can return to it by selecting the Configure, or Edit Source, link under the Source Config menu on the Workflow Main page.)
Once ClearCase is set up with AnthillPro (see Set Up ClearCase Base Snapshot View Repository), create a project.
Select the Mode and View Type once ClearCase has been selected as the repository type.
Mode. Choose Base.
View Type. Choose Snapshot.
Click Select.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
Load Rules. Give the Load Rules configured in the View Configuration Specifications to tell AnthillPro what projects, branches, and labels to use. AnthillPro requires the specs to be in the form
<vob-name><path>:<branch>:<label>. Each Load Rule must be input on a separate line.If the View Load Rules are configured with the value
BaseModeTest:Anthill-Example::, then they are input asvob-name BaseModeTest(following the form<vob-name><path>:<branch>:<label>) in the Load Rules field. Note that the Source Config deals with thevob-name BaseModeTestand that the project is located in theAnthill-Exampledirectory under our VOB.To build from the branch named test, the Load Rule would be
BaseModeTest:Anthill-Example:test: (all builds performed on the test branch).To perform a build on label 1.0.3 the Load Rule would be
BaseModeTest:Anthill-Example::1.0.3.To build from label 1.0.3 of the branch named test, the Load Rule would be
BaseModeTest:Anthill-Example:test:1.0.3.Example Load Rule Configuration
For the load rules below, AnthillPro needs to know the path and optional branch and label the configspec is checking out in order to find the changes and then apply any needed labels. For example, the branch and label would come from lines starting with element, paths come from the lines starting with load, etc.
element* CHECKEDOUT element/elementName/... .../elementNameApplication/LATEST element/elementName/... .../iter2_elementNameApplication/LATEST -mkbranch elementNameApplication element/mmisPortal/... /main/LATEST -mkbranch iter2_portal element* .../element_customization/LATEST element* .../main/LATEST load /elementNamePortal load /elementNameCommon load /elementNameFramework
For example, if you look at the first line in the load rules:
element/elementName/... .../elementNameApplication/LATESTmeans that for path
/elementNameyou need to get the code from theelementNameApplicationbranch (LATESTis the default label so you can ignore it when configuring AnthillPro). This translates in the following load rule (using the patternVOB:/path_in_vob:branch:label):elementName:/:elementNameApplication:In the same manner, the second line translates into
elementName:/:iter2_elementNameApplication:However, the
-mkbranchin the line is ignored when configuring AnthillPro since-mkbranchsays it's not about getting code but committing code back.For the line
element* .../element_customization/LATESTmeans that for every load rule we need to get the code from theelement_customizationbranch. This requires one load rule be configured in AnthillPro per load rule in ClearCase. Thus, you would have something like:elementName:/:element_customization:elementNameCommon:/:element_customization:elementNameFramework:/:element_customization:Note that
element* .../main/LATESTalso needs to be addressed. In the example, you will need to get code from the main branch. This should look something like:elementNamePortal:/::elementNameCommon:/::elementNameFramework:/::Create global labels. Check the box to create global labels. You can also specify in which VOBs those labels will be created (see below). If you do not specify any VOBs (below), the Load Rules will be used to determine all the VOBs that are used, and the labels will be created in those VOBs.
Create labels in VOBs. Please list the names of the VOBs (one per line) where the global labels should be created. If you are not creating global labels (option above is not selected) you can list all the VOBs used in your config spec or leave the field empty, and the Load Rules will be used to determine where the labels need to be created.
Host name. Provides the value for the
-hostparameter to be used in themkviewcommand. Use this filed only if the view and storage are in different locations.Global storage path (
gpath). Provides the value for the-gpathparameter to be used in themkviewcommand. Use this filed only if the view and storage are in different locations.Host storage path (
hpath). Provides the value for the-hpathparameter to be used in themkviewcommand. Use this filed only if the view and storage are in different locations.View Strategy. Select a view strategy:
Create a new view every time we build. If this option is chosen, AnthillPro will check for an existing snapshot view and remove it before creating a new view with every build. This option will ensure that the view always represents the state of the current build. Proceed to Item 4.
Create a new view only if one does not exist already. AnthillPro will check for an existing snapshot view. If one is found, a new view will not be created. If no existing view is found, AnthillPro will create a new one. This option allows you to use an existing view; however, that view may not represent the state of the latest build. Proceed to Item 5.
The view already exists and will be used every time. AnthillPro will not create a new view and use the existing view. This option will always use the view that previously exists. If no view exists, one must be created prior to using this option. Proceed to Item 6.
Create a new view every time we build View Strategy. Configure:
Working Directory Script. Select the Working Directory Script from the drop-down menu. The working directory is the location where the agent is going to run its commands. For example, if the working directory is
C:\projects\Project_A\every command AnthillPro issues will be from that specific directory.If no Working Directory Script is configured in the job, the script selected here will be used. See Working Directory Scripts.
View Storage Directory. Give the location of the view on the local machine. On Windows this will be a of the form
//host/share/view_storage.Project Name. Give the name to be used in creating the view name.
Config Spec. Provide the config spec to be used for the new view. Please replace any labels used in the config spec with a token.
For example:
/main/LATESTshould become/main/${LATEST}and/main/test/1.0.3should become/main/test/${1.0.3}.Place a time token after any element rules that do not load from a particular label: element
* /main/LATESTshould become element* /main/LATEST $[time.token]and element* /main/test/LATESTshould become element* /main/test/LATEST $[time.token].Do not assign the element
* /main/test/1.0.3a time token.Check New Configspec. Select here if you want to compare the newly set config spec against the user specified config spec. This option allows you to determine success based on the new config spec set on the view rather than the outcome of the command.
Label Script. Give the label to check out source from (if any).
Use Tags. Select here if you want your view to be globally created. Having this option checked can cause problems with creating and dropping snapshots if you wish to have the same snapshot on multiple agents.
Proceed to Item 7.
Create a new view only if one does not exist already View Strategy. Configure:
Working Directory Script. Select the Working Directory Script from the drop-down menu. The working directory is the location where the agent is going to run its commands. For example, if the working directory is
C:\projects\Project_A\every command AnthillPro issues will be from that specific directory.If no Working Directory Script is configured in the job, the script selected here will be used. See Working Directory Scripts.
View Storage Directory. Give the location of the view on the local machine. On Windows this will be a UNC path of the form
//host/share/view_storage.Project Name. Give the name to be used in creating the view name.
Config Spec. Provide the config spec to be used for the new view. Please replace any labels used in the config spec with a token.
For example:
/main/LATESTshould become/main/${LATEST}and/main/test/1.0.3should become/main/test/${1.0.3}.Place a time token after any element rules that do not load from a particular label: element
* /main/LATESTshould become element* /main/LATEST $[time.token]and element* /main/test/LATESTshould become element* /main/test/LATEST $[time.token].Do not assign the element
* /main/test/1.0.3a time token.Check New Configspec. Select here if you want to compare the newly set config spec against the user specified config spec. This option allows you to determine if success was based on the new config spec set on the view rather than the outcome of the command.
Label Script. Give the label to check out source from (if any).
Use Tags. Select here if you want your view to be globally created. Having this option checked can cause problems with creating and dropping snapshots if you wish to have the same snapshot on multiple agents.
Delete view-private files during cleanup. Select here if you would like AnthillPro to detect and delete any view-private files in the local view. This is highly recommended unless your build script handles cleanup of the view. Only the paths specified in the Load Rules above will be checked for view-private files.
Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File paths to exclude from changelog. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.Proceed to Item 7.
The view already exists and will be used every time View Strategy. Configure:
View Storage Directory. Give the location of the view on the local machine. On Windows this will be a UNC path of the form
//host/share/view_storage.Delete view-private files during cleanup. Select here if you would like AnthillPro to detect and delete any view-private files in the local view. This is highly recommended unless your build script handles cleanup of the view. Only the paths specified in the Load Rules above will be checked for view-private files.
Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File paths to exclude from changelog. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.Proceed to Item 7.
The first step in using a ClearCase UCM Dynamic View repository with AnthillPro is to configure it by following the Repositories link on the System page. The configuration will allow basic information regarding ClearCase to be reused by several project workflows. Once configured, the repository will be listed on the Repositories main page.
Once the main repository has been identified, your projects can then use the ClearCase repository. During project creation, associate the workflow with a specific ClearCase repository and determine the mode, view, and specify the Load Rules. See ClearCase UCM Dynamic View Source Configuration.
See also ClearQuest.
ClearCase must already be installed. See ClearCase documentation.
You must have administrative permissions. See Manage Security.
The cleartool executable and the Load Rules must be available to complete the configuration.
If you are not familiar with ClearCase, it is recommended to consult with your ClearCase administrator while configuring the integration.
Go to System > Repositories from the Project Support menu.
On the Repositories page, click the Create New button.
Select ClearCase from the drop-down menu and click Set.
Configure:
Name the repository. This is the name AnthillPro will use to identify this repository. This name does not correspond to the actual repository, and is simply an identifying label used by the AnthillPro system.
Description. Give an optional description.
Command Path. Provide the location of the ClearCase executable if it is not in the system path.
Click Save.
If not setting a Repository Trigger or Security, click Set then Done to complete. Otherwise proceed to item 7 to set a trigger or item 9 to set security.
Select the Trigger tab. To either deactivate or delete the repo trigger, click the appropriate button. If the repo trigger is deactivated/deleted, you will need to configure a workflow trigger for every project.
If not setting Security, click Activate then Done to complete. Otherwise click Activate and proceed to item 9.
Select the Security tab and click the Edit button. Check the appropriate boxes to determine user-role access (See Manage Security), and click Save.
Click Done.
Once the main ClearCase repository is identified (see Set Up ClearCase UCM Dynamic View Repository), configure the specific repository a workflow uses. During project creation, the originating workflow is first associated with the ClearCase repository. Once this is done, the Source Configuration page will automatically pop up. (However, if you choose not to configure the project source at initial creation, you can return to it by selecting the Configure, or Edit Source, link under the Source Config menu on the Workflow Main page.)
Once ClearCase is set up with AnthillPro (see Set Up ClearCase UCM Dynamic View Repository), create a project.
Select the Mode and View Type once ClearCase has been selected as the repository type.
Mode. Choose UCM.
View Type. Choose Use Dynamic.
Click Select.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
View Location. Give the location of the view on the local machine (AnthillPro Agent). For Windows this will be a UNC path of the form
//host/share/view_storage.View Name. If the rebase step is used, you must give the view name here. Otherwise, leave this field blank.
Stream Name. Give the ClearCase stream name that is used by this view.
Check the box if AnthillPro is to build the child stream. If the field is inactive, you cannot build child streams.
Project VOB Name. Give the project VOB name.
Paths. Give the paths to tell AnthillPro what projects, branches, and labels to use. A view in ClearCase can contain code from any number of VOBs. By giving the paths (each on its own line) you are telling AnthillPro which directories in which VOBs you want AnthillPro to use when checking for changes and when creating a baseline. AnthillPro requires the specs to be in the form
vob/path/to/files. For example, to perform a build on label 1.0.3, the Load Rule would beVOB/BaseModeTest/Anthill-Example/1.0.3.To build from label 1.0.3 of the branch named test, the Load Rule would be
VOB/BaseModeTest/Anthill-Example/test/1.0.3.Create global labels. Check the box to create global labels. You can also specify in which VOBs those labels will be created (see below). If you do not specify any VOBs (below), the Load Rules will be used to determine all the VOBs that are used and the labels will be created in those VOBs.
Create labels in VOBs. Please list the names of the VOBs (one per line) where the global labels should be created. If you are not creating global labels (option above is not selected) you can list all the VOBs used in your config spec or leave the field empty and the Load Rules from above will be used to determine where the labels need to be created in order to complete the labeling process successfully.
Delete view-private files during cleanup. Select here if you would like AnthillPro to detect and delete any view-private files in the local view. This is highly recommended unless your build script handles cleanup of the view. Only the paths specified in the Load Rules will be checked for view-private files.
Lock Objects. Please list the names of the objects (one per line) that you would like locked/unlocked during the build process. Use the following format:
type:Name@VOB(or refer to the lock/unlock ClearCase command reference for more details). Be advised that if you leave this field empty, there is nothing to prevent an update of the dynamic view while a build is in progress.Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File paths to exclude from changelog. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.
Click Save.
ClearCase UCM repository triggers allow you to create a single hook in the repository that is capable of triggering every workflow using this repository. For deliver events in your ClearCase repository, use Perl or a utility like wget or curl to generate an HTTP post to the URL specified in the trigger. The examples below are for shell scripts. The 'xxxx' values for pvob-name and stream-name should be replaced with the project VOB name and stream name that was delivered to.
By default, AnthillPro activates the repository trigger when the repository is configured. When configuring an AnthillPro project, the repo trigger is automatically generated for every workflow.
Using wget in a Unix/Linux shell script:
#!/bin/bash TRIGGER_URL="http://localhost:8080/trigger" CODE=f3b5110446797dbce6579d01fe55f5854ee370a2 wget --tries 1 --no-check-certificate "$TRIGGER_URL" \ --post-data="code=$CODE&pvob-name=xxxx&stream-name=xxxx" -O /dev/null
Using wget in a Windows shell script:
@echo off setlocal set TRIGGER_URL=http://localhost:8080/trigger set CODE=f3b5110446797dbce6579d01fe55f5854ee370a2 wget --tries 1 --no-check-certificate "http://localhost:8080/trigger" --post-data="code=%CODE%&pvob-name=xxxx&stream-name=xxxx"
Using curl in a Unix/Linux shell script:
#!/bin/bash TRIGGER_URL="http://localhost:8080/trigger" CODE=f3b5110446797dbce6579d01fe55f5854ee370a2 curl --retry 1 -k -d "code=$CODE&pvob-name=xxxx&stream-name=xxxx" -o /dev/null "$TRIGGER_URL"
Using curl in a Windows shell script:
@echo off setlocal set TRIGGER_URL=http://localhost:8080/trigger set CODE=f3b5110446797dbce6579d01fe55f5854ee370a2 curl --retry 1 -k -d "code=%CODE%&pvob-name=xxxx&stream-name=xxxx" -o /dev/null "%TRIGGER_URL%"
The first step in using a ClearCase UCM Snapshot View repository with AnthillPro is to configure it by following the Repositories link on the System page. The configuration will allow basic information regarding ClearCase to be reused by several projects. Once configured, the repository will be listed on the Repositories main page.
Once the main repository has been identified, your workflows can then use the ClearCase repository. During project creation, associate the project workflow with a specific ClearCase repository and determine the mode, view, and specify the Load Rules. See ClearCase UCM Snapshot View Source Configuration.
See also ClearQuest.
ClearCase must already be installed. See ClearCase documentation.
You must have administrative permissions. See Manage Security.
The cleartool executable and the Load Rules must be available to complete the configuration.
If you are not familiar with ClearCase, it is recommended to consult with your ClearCase administrator while configuring the integration.
Go to System > Repositories from the Project Support menu.
On the Repositories page, click the Create New button.
Select ClearCase from the drop-down menu and click Set.
Configure:
Name the repository. This is the name AnthillPro will use to identify this repository. This name does not correspond to the actual repository, and is simply an identifying label used by the AnthillPro system.
Description. Give an optional description.
Command Path. Provide the location of the ClearCase executable if it is not in the system path.
Click Save.
If not setting a Repository Trigger or Security, click Set then Done to complete. Otherwise proceed to item 7 to set a trigger or item 9 to set security.
Select the Trigger tab. To either deactivate or delete the repo trigger, click the appropriate button. If the repo trigger is deactivated/deleted, you will need to configure a workflow trigger for every project.
If not setting Security, click Activate then Done to complete. Otherwise click Activate and proceed to item 9.
Select the Security tab and click the Edit button. Check the appropriate boxes to determine user-role access (See Manage Security), and click Save.
Click Done.
Once the main ClearCase repository is identified (see Set Up ClearCase UCM Snapshot View Repository), configure the specific repository a workflow uses. During project creation, the originating workflow is first associated with the ClearCase repository. Once this is done, the Source Configuration page will automatically pop up. (However, if you choose not to configure the project source at initial creation, you can return to it by selecting the Configure, or Edit Source, link under the Source Config menu on the Workflow Main page.)
During source configuration, you must select a View Strategy. The strategy will determine how AnthillPro interacts with existing views and determine when AnthillPro should create a new view. Select a strategy that either (a.) creates a new view with every build; (b.) create a new view if and only if a view does not exist; or (c.) does not create a new view and uses an existing view. Only one view may be configured on an individual workflow; however, if a project has multiple workflows, a separate View Strategy may be used for each workflow. See View Strategy.
Once ClearCase is set up with AnthillPro (see Set Up ClearCase UCM Snapshot View Repository), create a new project.
Select the Mode and View Type once ClearCase has been selected as the repository type.
Mode. Choose UCM.
View Type. Choose Snapshot.
Click Select.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
View Location. Give the location of the view on the local (Agent) machine. On Windows this will be a UNC path of the form
//host/share/view_storage.View Name. If the rebase step is used, you must give the view name here. Otherwise, leave this field blank.
Stream Name. Give the ClearCase stream name that is used by this view.
Project VOB Name. Give the project VOB name.
Paths. Give the paths to tell AnthillPro what projects, branches, and labels to use. A view in ClearCase can contain code from any number of VOBs. By giving the paths (each on its own line) you are telling AnthillPro which directories in which VOBs you want AnthillPro to use when checking for changes and when creating a baseline. AnthillPro requires the specs to be in the form
vob/path/to/files. For example, to perform a build on label 1.0.3, the Load Rule would beVOB/BaseModeTest/Anthill-Example/1.0.3.To build from label 1.0.3 of the branch named test, the Load Rule would be
VOB/BaseModeTest/Anthill-Example/test/1.0.3.Is building in child stream. Check the box if AnthillPro is to build the child stream. If the field is inactive, you cannot build child streams. Only select this option if you are using a child stream off of the main development stream and nothing is delivered to this stream. This option tells AnthillPro to look for changes using the baseline activity set rather than looking for changes on the stream itself.
View Strategy. Select a view strategy:
Create a new view every time we build. If this option is chosen, AnthillPro will check for an existing snapshot view and remove it before creating a new view with every build. This option will ensure that the view always represents the state of the current build. Proceed to Item 4.
Create a new view only if one does not exist already. AnthillPro will check for an existing snapshot view. If one is found, a new view will not be created. If no existing view is found, AnthillPro will create a new one. This option allows you to use an existing view; however, that view may not represent the state of the latest build. Proceed to Item 5.
The view already exists and will be used every time. AnthillPro will not create a new view and use the existing view. This option will always use the view that previously exists. If no view exists, one must be created prior to using this option. Proceed to Item 6.
Create a new view every time we build View Strategy. Configure:
View Storage Directory. Give the location of the view on the local machine. On Windows this will be a of the form
//host/share/view_storage.Host name. Provides the value for the
-hostparameter to be used in themkviewcommand. Use this filed only if the view and storage are in different locations.Global storage path (
gpath). Provides the value for the-gpathparameter to be used in themkviewcommand. Use this filed only if the view and storage are in different locations.Host storage path (
hpath). Provides the value for the-hpathparameter to be used in themkviewcommand. Use this filed only if the view and storage are in different locations.Use Tags. Select here if you want your view to be globally created. Having this option checked can cause problems with creating and dropping snapshots if you wish to have the same snapshot on multiple agents.
Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File paths to exclude from changelog. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.Proceed to Item 7.
Create a new view only if one does not exist already View Strategy. Configure:
View Storage Directory. Give the location of the view on the local machine. On Windows this will be a UNC path of the form
//host/share/view_storage.Host name. Provides the value for the
-hostparameter to be used in themkviewcommand. Use this filed only if the view and storage are in different locations.Global storage path (
gpath). Provides the value for the-gpathparameter to be used in themkviewcommand. Use this filed only if the view and storage are in different locations.Host storage path (
hpath). Provides the value for the-hpathparameter to be used in themkviewcommand. Use this filed only if the view and storage are in different locations.Use Tags. Select here if you want your view to be globally created. Having this option checked can cause problems with creating and dropping snapshots if you wish to have the same snapshot on multiple agents.
Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File paths to exclude from changelog. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.Proceed to Item 7.
The view already exists and will be used every time View Strategy. Configure:
Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File paths to exclude from changelog. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.Proceed to Item 7.
ClearCase UCM repository triggers allow you to create a single hook in the repository that is capable of triggering every workflow using this repository. For deliver events in your ClearCase repository, use Perl or a utility like wget or curl to generate an HTTP post to the URL specified in the trigger. The examples below are for shell scripts. The 'xxxx' values for pvob-name and stream-name should be replaced with the project VOB name and stream name that was delivered to.
By default, AnthillPro activates the repository trigger when the repository is configured. When configuring an AnthillPro project, the repo trigger is automatically generated for every workflow.
Using wget in a Unix/Linux shell script:
#!/bin/bash TRIGGER_URL="http://localhost:8080/trigger" CODE=f3b5110446797dbce6579d01fe55f5854ee370a2 wget --tries 1 --no-check-certificate "$TRIGGER_URL" \ --post-data="code=$CODE&pvob-name=xxxx&stream-name=xxxx" -O /dev/null
Using wget in a Windows shell script:
@echo off setlocal set TRIGGER_URL=http://localhost:8080/trigger set CODE=f3b5110446797dbce6579d01fe55f5854ee370a2 wget --tries 1 --no-check-certificate "http://localhost:8080/trigger" --post-data="code=%CODE%&pvob-name=xxxx&stream-name=xxxx"
Using curl in a Unix/Linux shell script:
#!/bin/bash TRIGGER_URL="http://localhost:8080/trigger" CODE=f3b5110446797dbce6579d01fe55f5854ee370a2 curl --retry 1 -k -d "code=$CODE&pvob-name=xxxx&stream-name=xxxx" -o /dev/null "$TRIGGER_URL"
Using curl in a Windows shell script:
@echo off setlocal set TRIGGER_URL=http://localhost:8080/trigger set CODE=f3b5110446797dbce6579d01fe55f5854ee370a2 curl --retry 1 -k -d "code=%CODE%&pvob-name=xxxx&stream-name=xxxx" -o /dev/null "%TRIGGER_URL%"
If you use the Job Wizard to create a build job, only the generic job steps are used -- which should suffice for most builds. However, the integration also includes ClearCase-specific steps (commands, etc.) that you can add to your build job. While these steps are not required for a basic build, they may be helpful as you design more complicated build jobs.
When setting up a build and not using the Wizard, most jobs will contain the following steps:
Cleanup Step. Cleans up the workspace prior to populating it. This ensures that any files you might pick up from the build actually belong to the build and not a previous build.
Populate Workspace. Places the checked-out code (defined in the workflow's source configuration) in the workspace.
Get Changelog. The retrieved changelog is usually based on the changes made since the previous build. This step enables AnthillPro to extract data from the SCM and then store it in the AnthillPro data warehouse. Since AnthillPro stores the changelogs, it can parse the data, allowing you to override the default behavior. For example, you can select a starting point for the changelog based on criteria such as the latest production build.
Stamp. Applies a stamp to the build, which is used to identify the build within AnthillPro.
Get Dependency Artifacts. If your project depends on any other project, you need to specify it here. Otherwise, this step will just be skipped if no dependencies are defined.
Builder. Usually points to the location of tool or script used for the build.
Label Source. AnthillPro can also apply a label to the source code used in the build (e.g., snapshot, baseline). This unique identifier for a build can be used to recreate a build if necessary.
Assign Status - Success. Applies the status when the build completes successfully.
Assign Status - Failure. Applies the status when the build fails.
In addition, the ClearCase integration includes tool-specific job steps that may be added to the generic build job or used to replace one of the generic steps where appropriate. When configuring, the steps are available under the SCM folder:
ClearCase Changelog. Performs a ClearCase changelog.
ClearCase Cleanup. Perform a cleanup of the current ClearCase working directory.
ClearCase Label. ClearCase-specific label step.
Lock (ClearCase Base Dynamic Plugin only). Locks ClearCase resources.
Unlock (ClearCase Base Dynamic Plugin only). Unlocks ClearCase resources.
ClearCase Populate Workspace (Legacy integration only). Populates the workspace With source from ClearCase.
The first step in using a CVS repository with AnthillPro is to configure it by following the Repositories link on the System page. The configuration will allow basic information regarding CVS to be reused by several project workflows. Once configured, the repository will be listed on the Repositories main page.
Once the main repository has been identified, your workflows can then use the CVS repository. During project creation, associate the originating workflow with a specific CVS repository. See CVS Source Configuration.
You must have read and write permissions to the System page. See Manage Security.
A CVS repository must already be created. See CVS documentation.
In order to use ViewVC integration, the Source Configuration Repository Name field must be the actual name. It is not possible to use ViewVC if properties are set for the Repository Name field. See ViewVC.
Configure AnthillPro with an existing CVS repository. This example covers the configuration of a CVS repository for the Anthill Example project, as well as covering some of the variations needed to complete a configuration.
Go to System > Repositories from the Project Support menu.
Click the Create New button on the Repositories page.
Select CVS from the drop-down menu and click Set.
Configure the repository.
Name. This is the name AnthillPro will use to identify this repository. This name does not correspond to the actual repository, and is simply an identifying label used by the AnthillPro system.
Description. Provide description (optional).
CVSROOT. The CVSROOT tells AnthillPro the authentication method, the user name, the domain name, and the repository location. An example CVSROOT would be:
:pserver:anthill-example@cvs2.urbancode.com:/usr/local/anthill-test::pserveris the authentication method you are using to connect to the repository, and specifies that you are using a password server. If you omit this from the CVSROOT, CVS will use the RSH default.:anthill-exampleis the user name we want connected.@cvs2.urbancode.comis the machine host (domain) name.:/usr/local/anthill-testis the CVS repository location on the server.
If using an external protocol for authentication, specify
:ext. By specifying:ext, you can login with any authentication protocol for which a client can respond to the same command options/api as RSH.If you are using a fork or local server, you need to specify
:localor:forkin the CVSROOT.CVS_RSH. Specify the remote shell used to connect to the repository. Enter a value in this field to set the CVS_RSH environment variable. Use this field to also tell the CVS client which protocol to use when logging into the repository.
CVS Password. Provide the password corresponding to the account specified in the CVSROOT. (You will need to specify a password if you are using Kerberos or
:pserverfor the Anthill-Example project. You can use a pub_key/priv_key to handle authentication with RSH and SS. This means that you do not need to enter a password when authenticating in this fashion. It is also possible to perform a login with:sspi, Windows’ single sign-on, which does not require a password [because authentication is handled with Active Directory when logging into Windows]).Select either: No Password, Use Password, or Use Script.
No Password. If no password is associated with AnthillPro's CVS account, use this option.
Use Password. If a password is associate with AnthillPro's CVS account, select this potion. Give the password in the Password field and confirm the password.
Check the Use in CVSROOT box to add the password in the CVSROOT. The password will be hidden in all logs files. This is a workaround if CVS is unable to read the .cvspass file in certain scenarios.
Use Script (advanced). Give a parameterizable value that will resolve to the password. Use this instead of the Password field if the password will be stored in a secure property resolved at runtime. See Scripting.
Check the Use in CVSROOT box to add the password in the CVSROOT. The password will be hidden in all logs files. This is a workaround if CVS is unable to read the .cvspass file in certain scenarios.
Command Path. The location of the CVS executable, if not in the system path. If the CVS executable was not on the command path (as it was in the example), you would type it in the Command Path text field. If you do not want to ensure the executable is on the path of every agent, then you must set an agent property for every agent (in AnthillPro) with the path to the executable, and then reference that property in the Command Path field.
In a distributed environment, it becomes very difficult to put the executable on every agent path.
Repository Name. Give the name of the repository.
If using the ViewVC integration, the Repository Name field must be the ViewVC repository name. It is not possible to use ViewVC if properties are set for the Repository Name field. See ViewVC.
Source Viewer. Select the Source Viewer Type from the drop-down menu (if using the ViewVC integration). Otherwise select None. See ViewVC.
Is CvsNT. Select here if you are using a CvsNT repository. CvsNT cannot authenticate using AnthillPro’s normal means of password specification (writing the password and encrypting it to a .cvspass file in the user home directory). For example, on Windows, using CvsNT with
:pserverwill not work. By checking ‘Is CvsNT’, AnthillPro will run a CVS login command during every step. See CvsNT documentation.Place Password in CVSROOT. By selecting this option, you require the password to be added into the CVSROOT and to be hidden in the logs files. This is a workaround because CVS is unable to read the .
cvspassfile in certain scenarios. When printed out, the ENV_VARIABLES hide the password.Date Format. Give the date format to use when parsing change logs. The default is yyyy/MM/dd HH:mm:ss, which should work with older versions of CVS. If using a newer versions of CVS use: yyyy-MM-dd HH:mm:ss. See CVS documentation.
Click Set.
Select the Security tab and click the Edit button. Determine permissions and click Save. Click Done. See Manage Security.
Click Done.
CVS configuration is contained in a special module called CVSROOT. You must first configure a CVS repository and then checkout this module before you can continue.
The file you are interested in is called loginfo. It has a special format that must be followed. Each line contains a regular expression that matches the module repository path, a space, and a shell command. The default file CVS provides contains comments that explains this in more detail.
In the command, you use a utility like Wget to generate an HTTP request to the URL specified in the trigger:
^MyProject (wget -t 0 https://server/trigger --post-data='triggerId=31&code=95cde532437151c551cf062bf93c0d12de9209c7' -O - &>/dev/null)
A nested module would be handled like this:
^MyProject/SubProject (wget -t 0 https://server/trigger --post-data='triggerId=31&code=95cde532437151c551cf062bf93c0d12de9209c7' -O - &>/dev/null)
Once the main CVS repository is identified (see Set Up CVS Repository), configure the specific repository a workflow uses. During project creation the originating workflow is first associated with the CVS repository. Once this is done, the Source Configuration page will automatically pop up. (However, if you choose not to configure the project source at initial creation, you can return to it by selecting the Configure, or Edit Source, link under the Source Config menu on the Workflow Main page.)
Once CVS is set up with AnthillPro (see Set Up CVS Repository), create a new project.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
Working Directory Script. Select the Working Directory Script from the drop-down menu. The working directory is the location where the agent is going to run its commands. For example, if the working directory is
C:\projects\Project_A\every command AnthillPro issues will be from that specific directory.If no Working Directory Script is configured in the job, the script selected here will be used. See Working Directory Scripts.
Module Name. Give the CVS module name to be retrieved by this workflow. See CVS documentation.
Branch. Give the CVS branch name to be retrieved by this workflow. See CVS documentation.
Tag. If using tags, give the tag to use for checkout. This may include variables passed to the workflow via
${property:Name}format. See Scripting.Directory Offset. Give the sub-directory where this module is to be placed within the working directory. If the root of the working directory is to be used, leave this item blank.
Local Folder Only. Check the box to only retrieve files from the specified folder (for non-recursive checkout).
Prune Empty Directories. Check the box to clean up empty directories. If selected, the Prune Empty Directories option will delete any empty directories during checkout.
Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File paths to exclude from changelog. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.
Click Save.
The first step in using a Serena Dimensions repository with AnthillPro is to configure it from the Repositories item on the Administration page (see Set Up Dimensions Repository). This configuration will allow basic information about where the Dimensions repository is, and how to connect to it to be reused by several project workflows. Once the main repository has been identified, your projects can then use the Dimensions repository during workflow source configuration (see Dimensions Source Configuration). During project creation, the workflow is associated with a specific Dimensions repository.
Dimensions must already be installed.
You must have administrative permissions. See Manage Security.
Go to System > Repositories from the Project Support menu.
On the Repositories page, click the Create New button.
Select Dimensions from the drop-down menu and click Set.
Configure repository:
Name the repository. This name is used throughout AnthillPro. For example, the name given here will be used during Source Configuration.
Description. Give an optional description.
DMCLI Command Path. Give the usual command path to the dimensions command line utility. This field is only necessary if the location of the
dmcliexecutable, if not in system path.Download Command Path. Give the location of the
downloadexecutable, if not in system path. In order to make the populate command sane, you can use another Dimensions package, -- the Dimensions Make Package -- which provides the client with subsequent commands for download and upload. In order to use the Dimensions driver, have the Dimensions Make Package installed and on the path, or provide the path to it here.User Name. Provide a Dimensions user name for accessing Dimensions database. We recommend creating a user exclusively for AnthillPro. This allows for clear traceability, security management, and easier transition as the team changes.
Password. Give the user’s password. Use either Set Password, or Use Script:
Set Password. Select this option to use the password associated with the AnthillPro user account. Input the password and confirm.
Use Script (advanced). Give a parameterizable value that will resolve to the password. Use this instead of the Password field if the password will be stored in a secure property (which is resolved at runtime). See Scripting.
Host Address. Give the location of the Dimensions host.
Database Name. Provide the name of the dimensions database.
Database Schema Name. Give the database schema to connect to for the given database configured above.
Click Set.
Select the Security tab and click the Edit button. Determine permissions, click Save, and then click Done.
Click Done.
Once the main Dimensions repository is identified (see Set Up Dimensions Repository), configure the specific repository a workflow uses. During project creation, the originating workflow is first associated with the Dimensions repository. Once this is done, the Source Configuration page will automatically pop up. (However, if you choose not to configure the project source at initial creation, you can return to it by selecting the Edit Source link on the Workflow Main page.)
Once Dimensions is set up with AnthillPro (see Set Up Dimensions Repository), create a project.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
Workset Name. Give the name of the workset to use. You may need to create a workset that frames the proper items to be built.
Note that if you do not provide a Workset, you must provide a Baseline. However, you cannot provide both.
Baseline Name. Give the name of the baseline to build from. This could be a dynamic label like
${property:baseline}passed in at build time.Note that if you do not provide a Baseline, you must provide a Workset. However, you cannot provide both.
Part Name. Provide the name of the Part to use when labeling. This is the part name created by Dimensions.
Template Id. Optional setting to use a Dimensions base-lining template when applying a baseline. If left empty, the
ALL_ITEMS_LATESTis used which will apply the baseline to the most recent version of every item in the baseline.Product Id. Give the Dimensions project id (project name) for the project to be built.
Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File paths to exclude from changelog. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.
Click Save.
The first step in using a File System repository with AnthillPro is to configure it by following the Repositories link on the System page. The configuration will allow basic information regarding the File System to be reused by several project workflows. Once configured, the repository will be listed on the Repositories main page.
Once the main repository has been identified, your workflows can then use the File System repository. During project creation, associate the workflow with a specific File System repository. See File System Source Configuration.
You must have administrative permissions. See Manage Security.
The directory (file system) location must be available.
Go to System > Repositories from the Project Support menu.
On the Repositories page, click the Create New button.
Select File System from the drop-down menu and click Set.
Configure repository:
Name the file system repository.
Description. Give an optional description.
Click Set.
Select the Security tab. See Manage Security.
Click Edit, determine permissions, click Save, and then click Done.
Click Done.
Once the main File System repository is identified (see Configure File System Repository), configure the specific repository a workflow uses. During project creation, the originating workflow is first associated with the File System repository. Once this is done, the Source Configuration page will automatically pop up. (However, if you choose not to configure the project source at initial creation, you can return to it by selecting the Configure, or Edit Source, link under the Source Config menu on the Workflow Main page.)
Once the File System is set up with AnthillPro (see Configure File System Repository), create a project.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
Working Directory Script. Select the Working Directory Script from the drop-down menu. The working directory is the location where the agent is going to run its commands. For example, if the working directory is
C:\projects\Project_A\every command AnthillPro issues will be from that specific directory.If no Working Directory Script is configured in the job, the script selected here will be used. See Working Directory Scripts.
Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File paths to exclude from changelog. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.
Click Save.
Because it is simple to set up, the File System Repository is typically used to perform builds on a local machine. Once configured (see Configure File System Repository), the File System is usually identified in the Set Working Directory step of the build job.
This section only covers the most common steps necessary to use a File System Repository.
Go to Administration, select the appropriate project, and click the Add Job icon.
On the New Job Configuration page, choose No (do not use the Job Wizard). Click Select.
Follow the steps for creating a build job.
Set Working Directory. Click Create Step. Expand the Miscellaneous folder, select the Set Working Directory step, and click Select.
Select New Script.
Name the script.
Description. Provide a description.
Script. Give the working directory path. This can be hard coded (e.g., C:\directoryname) or include variables and scriptlets. See Scripting.
If a Set Working Directory job step is used, it will always override the Working Directory Script selected during Source Configuration (see File System Source Configuration). For example, adding a job step that sets the Working Directory to
C:\Project_A\Subproject_01will override the Working Directory (ofC:\Project_A\) selected during Source Configuration. The job will always be run in theC:\Project_A\Subproject_01directory. Before changing the Working Directory, see Working Directory Scripts.Click Save.
Select the newly created script from the drop-down menu.
Clean Working Directory. Check the box to erases all files and subdirectories in the Working Directory when this step runs.
If selecting this option, ensure that the Working Directory is not set to something like
C:orC:\because the entire contents of the C drive will be permanently removed.Also note that if the Working Directory of
C:\Project_A\is set to clean up the workspace, the contents ofC:\Project_A\Subproject_01will be removed as well. This may have an adverse effect on jobs that use theC:\Project_A\Subproject_01directory.Show Additional Options (advanced). Select the Show Additional Options link to configure more options.
Is Active. Select No to temporarily deactivate the step without deleting it; otherwise select Yes.
Continuation Condition. Select the condition which must be met for the process to continue (all steps pass; previous step passed; any step failed; always; or never).
Ignore Failures. Select Yes if this step should not affect the determination for step continuation or the status determination of the job.
PostProcessingScript. Select a script for determining when commands should count as fail or succeed.
Timeout. Enter the time in minutes after the start of the step when AnthillPro will consider the step as timed out and abort it.
Click Save.
The first step in using a Git repository with AnthillPro is to configure it by following the Repositories link on the System page. The configuration will allow basic information regarding Git to be reused by several project workflows. Once configured, the repository will be listed on the Repositories main page.
After the main repository has been identified, your workflows can then use the Git repository. During project creation, associate the project workflow with a specific Git repository and create a build job that includes the Git job steps. AnthillPro has four Git-specific steps that are used during job creation: cleanup, populate workspace, get changelog, and label. If you use the Job Wizard, AnthillPro will automatically add these steps during job configuration; however, if you create your own job, you will need to add these steps yourself (usually in the order given above).
AnthillPro and Cloned Git Repositories. When the configured workflow is run, AnthillPro will create a clone of the repository on the agent that is going to perform the build and check out a particular revision and then perform a build based on that revision. Because cloning a repository can be resource heavy, AnthillPro can store the cloned repository on the agent, so only the changes are updated on the cloned repository when the workflow is run again. To keep a cloned repository on the agent, (a.) do not add the Git Cleanup (remove it if you used the Job Wizard); and (b.) do not check the Clean Workspace box when configuring the Git Populate Workspace step. Otherwise, AnthillPro will clone the repository every time a build is run.
Git must already be installed. See Git Documentation.
You must have administrative permissions. See Manage Security.
The location of the
gitexecutable, if not in the system path, must be configured under the System > Repositories.
Go to System > Repositories from the Project Support menu.
On the Repositories page, click the Create New button.
Select Git from the drop-down menu and click Set.
Configure repository:
Name the repository. This is the name AnthillPro will use to identify this repository.
Description. Give an optional description.
Command Path. Provide the location of the
gitexecutable, if not in the system path. See Git Documentation for information on identifying the Git executable.
Click Set.
Click Done.
Once the main Git repository is identified (see Set Up Git Repository), configure the specific repository a workflow uses. During project creation, the originating workflow is first associated with the Git repository. Once this is done, the Source Configuration page will automatically pop up. (However, if you choose not to configure the project source at initial creation, you can return to it by selecting the Edit Source link on the Workflow Main page.)
Once Git is set up with AnthillPro (see Set Up Git Repository), create a project.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
Working Directory Script. Select the Working Directory Script from the drop-down menu. The working directory is the location where the agent is going to run its commands. For example, if the working directory is
C:\projects\Project_A\every command AnthillPro issues will be from that specific directory.If no Working Directory Script is configured in the job, the script selected here will be used. See Working Directory Scripts.
Repository URL. Give the location of the repository the workflow is to use. By default, AnthillPro clones this repository on the agent, and then uses the clone to build from. If, during job configuration, you add the Git Cleanup step (or check the Clean Workspace box when configuring the Git Populate Workspace step), the cloned repository will be removed every time a build is run. If you want to keep the cloned repository on the agent, see AnthillPro and Cloned Git Repositories.
Repository Name. Give the name used to identify the repository in AnthillPro. This name does not correspond to the actual Git repository, and is simply an identifying label used by the AnthillPro system.
Revision. Optionally, give the revision or tag name to use when cloning and/or updating the repository.
Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File paths to exclude from changelog. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.
Click Save.
Information for connecting to a Harvest Repository can be shared by many projects. A new Harvest repository can be registered with AnthillPro in the Repositories section on the Administration page.
Harvest must already be installed.
You must have administrative permissions. See Manage Security.
To configure the repository:
Go to System > Repositories from the Project Support menu.
On the Repositories page, click the Create New button.
Select Harvest from the drop-down menu and click Set.
Configure repository:
Name the repository. This is the name AnthillPro will use to identify this repository.
Description. Give an optional description.
Broker. Enter the Harvest broker to connect through.
User Name. Give the user name used to connect to AnthillPro. For test purposes, this could be the Harvest user name of a developer or Administrator on the project. In production, we recommend creating a user exclusively for AnthillPro for clear traceability, security management and easier transition as the team changes.
Password. Provide the password corresponding to the account specified in the Username field. Select either: No Password, Use Password, or Use Script.
No Password. If no password is associated with AnthillPro's Harvest account, use this option.
Use Password. If a password is associate with AnthillPro's Harvest account, select this potion. Give the password in the Password field and confirm the password.
Use Script (advanced). Give a parameterizable value that will resolve to the password. Use this instead of the Password field if the password will be stored in a secure property resolved at runtime. See Scripting.
Revision Date Format. Specify the format. AnthillPro retrieves revision histories for you project. Depending on your locale, it may format dates in different ways. If the default value fails for you, adjust this value to match the dates logged by the get changelog step of a build.
Command Location. If the Harvest command line client is not on the path, tell AnthillPro where it is installed on the agent(s).
Click Set.
Select the Security tab and click the Edit button. Determine permissions, click Save, and then click Done.
Click Done.
The Repository configuration above declares how projects can connect to a Harvest Repository. A project needs to specify some rules for what source control should be retrieved to build from. Commonly, as a project matures, there will be a handful of source configurations created for the single project. Perhaps one for an old maintenance branch and another for the current development.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
Configuration Name and Description. These are used exclusively as identifies within AnthillPro. Typical source configuration names would be ‘Work State’ to indicate the rules used. The description is optional and may go into more depth.
Work Directory Script. This determines where on the agent the project will be checked out and built from. The default value works well. It works from the a directory named after the project under the Agent’s AnthillPro jobs directory.
User Exclusions. This feature is usually not used and can be ignored safely. To use it, list users whose changes should be ignored by the system. This is most commonly used when there is a special user that automatically updates the project on a regular basis whose changes are outside the scope of what AnthillPro should be interested in. Less frequently this feature is used to ignore users with access to the source who are not part of the core development team (documentation writers).
File Exclusions. This feature is usually not used and can be ignored safely. To use it, list file paths which AnthillPro should not track changes for. Most commonly this is used to exclude a ‘docs’ directory or some similar set or resource which the development team chooses to ignore from a process stand point.
Project Name. Enter the Harvest project name the sources should be retrieved from.
State. Enter the state from which to retrieve sources. If this source configuration is here to enable builds from a snapshot, the Snapshot state would be appropriate. Otherwise, a Work state is more likely.
View Path. Enter the view path to retrieve the sources from.
Package. Enter a package name here only if you want to restrict the retrieval of files to a particular package. To require a user to specify the package at build time, enter a scripted package name like
${property:PACKAGE}and add a required PACKAGE property to the build from package workflow.File Pattern. Enter the file pattern used to retrieve files from the view path. To retrieve every file on that path, use " * ".
Package. Enter a name here only if you want to restrict the retrieval of files to a particular package. To require a user to specify the snapshot at build time, enter a scripted snapshot name like
${property:Snapshot}and add a required ‘Snapshot’ property to the build from snapshot workflow.
Every source control system has some similar actions that are used in the generic build jobs. But custom jobs can expose special behavior unique to the SCM tool. Steps are available to checkout source; to get a change log; to approve a package; to promote the code used in the build; to demote that code; and to create a new snapshot. Most of the steps (available under the Source Steps folder during job configuration) have minimal configuration but provide the option to specify the name of the Harvest process to use. For instance, if the ‘checkout for browsing’ process should be used instead of the default checkout process, that can be specified.
The first step in using an MKS Integrity repository with AnthillPro is to configure it from the Repositories item on the System page. This configuration will allow basic information about where the Integrity server is, and how to connect to it to be reused by several projects.
Name the repository. This is the name AnthillPro will use to identify this repository.
Description. Give an optional description.
Hostname. The host name or IP address of the MKS Source Integrity server.
Port. The port the Source Integrity server is listening on.
Username. The MKS Source Integrity user name that will be used to connect to the server.
Password. Provide the password corresponding to the account specified in the Username field. Select either: Set Password or Use Script.
Set Password. If a password is associate with AnthillPro's Integrity account, select this potion. Give the password in the Password field and confirm the password.
Use Script (advanced). Give a parameterizable value that will resolve to the password. Use this instead of the Password field if the password will be stored in a secure property resolved at runtime. See Scripting.
Command Path. The location of the si executable. This value can take on a value that changes depending on the agent like,
${env\MKS_HOME}\bin.Date Format. Give the date format to use when parsing change logs if other than the default MMM dd, yyyy - hh:mm a.
Each project will have on or more source configurations. These provide a template for a set of code to checkout. Typically, a source configuration is set up for each major concurrent line of development (branch). There may also be a template for building from a specific label.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
Project File Name. The project file AnthillPro should reference when communicating with MKS. By default that project file is named
project.pjand that what AnthillPro assumes if left blank.Project Directory. The path to the project file on the MKS integrity server based on its directory structure.
Label Name. Build from a specific label. This could be a hard-coded floating label. Or a dynamic label like
${property:label}passed in at build time.Branch Name. Build from a branch. Like label, a dynamic property is allowed.
The first step in using a Mercurial repository with AnthillPro is to configure it by following the Repositories link on the System page. The configuration will allow basic information regarding Mercurial to be reused by several project workflows. Once configured, the repository will be listed on the Repositories main page.
Once the main repository has been identified, your workflows can then use the Mercurial repository. During project creation, associate the project workflow with a specific Mercurial repository. See Mercurial Source Configuration.
Mercurial must already be installed. See Mercurial Documentation.
You must have administrative permissions. See Manage Security.
The location of the
hgexecutable, if not in system path, must be available.
Go to System > Repositories from the Project Support menu.
On the Repositories page, click the Create New button.
Select Mercurial from the drop-down menu and click Set.
Configure repository:
Name the repository.
Description. Give an optional description.
Command Path. Provide the location of the
hgexecutable, if not in the system path. See Mercurial Documentation for information on identifying the Mercurial executable.
Click Set.
Click Done.
Once the main Mercurial repository is identified (see Set Up Mercurial Repository), configure the specific repository a workflow uses. During project creation, the originating workflow is first associated with the Mercurial repository. Once this is done, the Source Configuration page will automatically pop up. (However, if you choose not to configure the project source at initial creation, you can return to it by selecting the Edit Source link on the Workflow Main page.)
Once Mercurial is set up with AnthillPro (see Set Up Mercurial Repository), create a project.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
Working Directory Script. Select the Working Directory Script from the drop-down menu. The working directory is the location where the agent is going to run its commands. For example, if the working directory is
C:\projects\Project_A\every command AnthillPro issues will be from that specific directory.If no Working Directory Script is configured in the job, the script selected here will be used. See Working Directory Scripts.
Repository URL. Give the location of the repository the project is to use.
Repository Name. Give the name of the existing repository. If one does not already exist, provide a name to create a new repository. This is the name AnthillPro will use to identify this repository.
Revision. Optionally, give the revision or tag name to use when cloning and/or updating the repository.
Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File paths to exclude from changelog. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.
Click Save.
The first step in using a Perforce repository for your AnthillPro projects is to let AnthillPro know where your repository is, and how to connect to it. This is done on the System page, so you will need administrative permissions to configure a repository. Once the repository configuration is set up, each workflow will need to be configured with the project's specific source configuration. To get started:
Go to System > Repositories > Create New.
Select Perforce from the drop-down menu and click Set.
Depending on how AnthillPro was installed, you may see Perforce-Plugin in the menu. While the Plugin integration differs, the general configuration process is the same.
The Perforce Plugin allows you to past a copy of the Perforce client spec during source configuration if you set AnthillPro to create a new client spec -- this option is not available in the standard integration.
The integration is written as an AnthillPro Plugin, included in the normal distribution. For older AnthillPro 3.7 versions, you will need to download the integration from Supportal and then upload it to the server. Once uploaded, ensure the Plugin is active.
The remainder of this section assumes you are using the standard integration.
Configure the repository:
Name. Give a name for this configuration. What you give here will be used throughout AnthillPro. For example, when performing source configuration on a workflow, the name given here will be displayed to the user.
Description. You can give a short description, if desired. Often, users will put the repo's URL in the description, especially if they have multiple repositories configured.
Port. This is the server name and port used to connect to the Perforce server. Perforce defaults to the 1666 port.
Username. The user name that AnthillPro will use to connect to the server. You can either create a new Perforce user (e.g., Anthill) or have AnthillPro connect to Perforce via an existing user.
Password. Provide the password corresponding to the account specified in the Username field. Select either: No Password, Use Password, or Use Script.
No Password. If no password is associated with AnthillPro's Perforce account, use this option.
Use Password. If a password is associate with AnthillPro's Perforce account, select this potion. Give the password in the Password field and confirm the password.
Use Script (advanced). Give a parameterizable value that will resolve to the password. Use this instead of the Password field if the password will be stored in a secure property resolved at runtime. See Scripting.
Command Path. Provide the location of the Perforce executable (p4) if it is not in the system path. This value can take on a value that changes depending on the agent, for example
${env\P4_HOME}.Character Set. The optional client character set.
Command Character Set. The optional client command-line character set.
Click Save. To use Perforce with an AnthillPro project, see Perforce Source Configuration.
To configure the source for a project, make sure you have already configured your Perforce repository in AnthillPro. Each project may have one or more source configurations that provide a template for a set of code AnthillPro will checkout. Typically, a source configuration is set up for each major concurrent line of development (branch or view). There may also be a template for building from a label.
| If you are using the Perforce Plugin, you can past a copy of the Perforce client spec during source configuration if you set AnthillPro to create a new client spec. |
Once you have created a project, you will need to select the add workflow icon under the Actions menu. Give the workflow's basic configuration and then configure the source as follows:
Select the Perforce repository configuration you created earlier and click Set. See Perforce if you have not configured the repository yet.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
Client. There are two options for setting up the Perforce client. Use either an existing Perforce client configured on the build machine(s) or create a new client spec at runtime.
Use existing client spec. Give the name of the Perforce client that should be used. If you only have a single build machine, this option should be fine. However, when multiple machines (i.e., agents) are used to run a build, this approach can introduce risk as the configuration of the clients may not be done at the same time. If you have multiple build machines, it is best to use the Create new client spec option.
Create new client spec. Give a template for a new client, and have AnthillPro set up the clients on the fly with each build. The Working Directory Script dictates where the client will be put on the host machine.
Name. This name corresponds with Perforce client names. For the name of the new client spec, you can use a script that would ensure a unique name for each agent in order to avoid problems with concurrent builds. You can use something similar to
myproject-${agent:locked/agent.name}and replace 'myproject' with the correct project name.Template Name. Give the name of the Perforce template you want AnthillPro to use to create the client.
Working Directory Script. Select the Working Directory Script from the drop-down menu. The working directory is the location where the agent is going to run its commands. For example, if the working directory is
C:\projects\Project_A\every command AnthillPro issues will be from that specific directory. If no Working Directory Script is configured in the job, the script selected here will be used. See Working Directory Scripts.
Label Script. Build from a specific label. This could be a hard-coded floating label. Or a dynamic label like
${property:label}passed in at build time.Delete Workspace Files. Select to do clean builds (deletes all the files in the workspace before repopulating the workspace).
Do Not Update the Perforce Have List. Enable this to pass the '-p' option on the p4 sync command that will not update the Perforce have list. This option is only available to later versions of Perforce. Using this at the source config level will prevent you from being able to label the source checked out. You can also set this on the individual populate workspace step.
Preserve Unlabeled Files. This is used for patch builds. If you are checking out from a label (see above) and want to check the label out over the top of an existing workspace.
Do Not Limit Labels to Client Spec. This is used to apply the same label to multiple projects. This means that a label will be applied cumulatively.
Login Before Each Step. If Perforce authentication is done through LDAP, commands must be run after doing a full login, not just passing the credentials at the command line. This check box will use that approach.
Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File paths to exclude from changelog. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.
Click Save.
To use a PVCS repository with AnthillPro, configure it from the Repositories item on the System page. The configuration will allow basic information regarding the PVCS server to be reused by several project workflows. Once configured, the repository will be listed on the Repositories main page.
See also PVCS Tracker.
You must have administrative permissions. See Manage Security.
The PVCS Project Database path must be available to complete the configuration.
Go to System > Repositories from the Project Support menu.
On the Repositories page, click the Create New button.
Select PVCS from the drop-down menu and click Set.
Configure repository:
Name the repository.
Description. Give an optional description.
Username. Give the name AnthillPro should use to connect to the repository.
Password. Provide the password corresponding to the account specified in the Username field. Select either: No Password, Use Password, or Use Script.
No Password. If no password is associated with AnthillPro's PVCS account, use this option.
Use Password. If a password is associate with AnthillPro's PVCS account, select this potion. Give the password in the Password field and confirm the password.
Use Script (advanced). Give a parameterizable value that will resolve to the password. Use this instead of the Password field if the password will be stored in a secure property resolved at runtime. See Scripting.
Project Database. Provide the path to the project database (variables may be used).
Command Line Date Format. Give the date format to use with vlog command.
Changelog Date Format. Provide the date format used in reports that were created using the vlog command.
Command Path. Provide the path to the pcli, vcs, and vlog executables if they are not in the system path.
Click Set.
Select the Security tab. See Manage Security.
Click Edit, determine permissions, click Save, and then click Done.
Click Done.
The first step in using a Rational Team Concert (RTC) repository with AnthillPro is to configure it by following the Repositories link on the System page. The configuration will allow basic information regarding RTC to be reused by several project workflows. Once configured, the repository will be listed on the Repositories main page.
| The integration is written as an AnthillPro Plugin, included in the normal distribution. For older AnthillPro 3.7 versions, you will need to download the integration from Supportal and then upload it to the server. Once uploaded, ensure the Plugin is active. |
After the main repository has been identified, your workflows can then use the RTC repository. During project creation, associate the project workflow with a specific RTC repository (see Rational Team Concert (SCM) Source Configuration) and create a build job that includes the RTC job steps.
You must have administrative permissions. See Manage Security.
The RTC client must be installed on your AnthillPro agents in the build environment. See Environments for more.
The RTC server URL is required to configure the integration.
The RTC user name and password AnthillPro will use to contact the server must be created in RTC prior to configuring the integration.
The RTC integration must be configured before you can run any builds. The information given here will be reused by all of your projects that use the RTC repository. If you have multiple instances of RTC (i.e., they are completely different URLs), configure an integration for each one.
Go to System > Repositories under the Project Support menu.
On the Repositories page, click the Create New button.
Select RTC-SCM-Plugin from the drop-down menu and click Set.
On the Main tab, configure repository:
Name the repository.
Description. Give an optional description.
Command Path. Provide the full path of the SCM executable, including the file name. If the executable is already on the path, leave this filed blank.
RTC server URL. Enter the URL of the RTC server. For example: https://myserver:9443/jazz.
Repository Username. Give the user name to use when accessing the repository.
Repository Password. Provide the password corresponding to the account specified in the Repository Username field.
Confirm password.
Click Done and see Rational Team Concert (SCM) Source Configuration.
Once the main RTC repository is identified (see Set Up Rational Team Concert (SCM) Repository), configure the specific repository a workflow uses. During project creation, the originating workflow is first associated with the RTC repository type. Once this is done, the Source Configuration page will automatically pop up. (However, if you choose not to configure the project source at initial creation, you can return to it by selecting the Edit Source link on the Workflow Main page.)
Once RTC is set up with AnthillPro, create a project. If you are unfamiliar with AnthillPro, see Setting Up a Build for help.
Go to the originating workflow. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
Working Directory Script. Select the Working Directory Script from the drop-down menu. The working directory is the location where the agent is going to run its commands. For example, if the working directory is
C:\projects\Project_A\every command AnthillPro issues will be from that specific directory.If no Working Directory Script is configured in the job, the script selected here will be used. See Working Directory Scripts.
Name. Give a name for this configuration to be displayed on the Main tab.
Workspace Name. Enter the name of the workspace that is going to be used. If the workspace does not exist one will be created based on the name you give here. You can use an alias as well but only for existing workspaces.
Stream. Provide the name or alias of the default flow target stream for the workspace above.
Directory Offset. Give the offset from the current working directory where the local workspace is created. If there is no offset, leave this field blank.
Build Snapshot Name. Specify the name of the snapshot AnthillPro should create for every build. For example, if you use the default of "anthill-
${bsh:BuildLifeLookup.getCurrent().getId()}," the shapshot created will append "anthill-" with the current Build Life.Build Snapshot Description. Provide the description of the snapshot AnthillPro should create for every build. This is the description of the snapshot given above. For example, if you use the default of "Created by AnthillPro for Buildlife:
${bsh:BuildLifeLookup.getCurrent().getId()}," the description created will append "Created by AnthillPro for Buildlife:" with the current Build Life.Component List. Give a comma-separated list of components (name or alias) to load in the local workspace. Leave blank to load all components.
Include Root. Select here to load component roots as directories on the file system.
Force. Select here to overwrite existing files when loading.
Baseline. If you want to build from a baseline, enter the baseline name or alias here. If you specify a snapshot below, leave this field blank.
Snapshot. If you want to build from a snapshot, enter the snapshot name or alias here. If you specify a snapshot here, do not define the baseline above.
Exclude Users. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File Filters. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.Repository. Select the correct integration from the drop-down menu (this is the integration configured in the Set Up Rational Team Concert (SCM) Repository section). If you configured multiple RTC repositories on the AnthillPro System page, make sure you select the correct one.
Click Save and see Rational Team Concert (SCM) Build Jobs.
Typically, your RTC build job will include the following steps, in the order presented (the Job Wizard can be a helpful tool when configuring the job):
Cleanup Workspace. This steps cleans up the workspace used for previous builds.
Populate Workspace. Populates the workspace with the files necessary to run the build.
Get Changelog. This step works by locating a prior Build Life and getting the source changes since the prior Build Life up to the current source. The prior Build Life is located by using status and/or stamp requirements.
Create Stamp. Applies a unique stamp to the build.
Resolve Dependency Artifacts. Retrieves all artifacts generated this Build Life's dependencies.
Build. This step will execute your build script (e.g., Ant, Groovy, Make) or invoke another builder.
Label Source. Allows you to specify a particular label that you would like to apply to the source.
Publisher. The publisher steps typically send information and files associated with the build to other parts of the AnthillPro system or AnthillPro users via notifications. For example, the Artifact Deliver step that sends the build artifacts to Codestation, AnthillPro's artifact-management system.
There are a number of other publishers you can include. You can view them on the Steps page in the Publishers folder.
Assign Status - Success. Assigns the status of Success if the job completes.
Assign Status - Failure. Assigns the status of Failure if the job does not complete.
In addition, AnthillPro has four RTC-specific steps you
can use. Typically, these steps will not be used; however,
depending on your processes, it may be necessary to use one of
the RTC-specific steps. It is recommended to configure your
build job as outlined above. This will allow you to easily
switch source, etc.:
|
The first step in using an StarTeam repository with AnthillPro is to configure it from the Repositories item on the System page. This configuration will allow basic information about where the StarTeam server is, and how to connect to it to be reused by several projects.
Server. The host name or IP address of the StarTeam server. You can find this on the server settings dialog in the StarTeam Client.
Port. The port the StarTeam server is listening on. You can find this on the server settings dialog in the StarTeam Client.
Username. The StarTeam user name that will be used to connect to the server.
Password. Provide the password corresponding to the account specified in the Username field. Select either: No Password, Use Password, Use Script, or Use File.
No Password. If no password is associated with AnthillPro's StarTeam account, use this option.
Use Password. If a password is associate with AnthillPro's StarTeam account, select this potion. Give the password in the Password field and confirm the password.
Use Script (advanced). Give a parameterizable value that will resolve to the password. Use this instead of the Password field if the password will be stored in a secure property resolved at runtime. See Scripting.
Use File. Instead of using the password field above, if this is set it will use the password found in the specified file.
Date Format. StarTeam dates that must be parsed by AnthillPro can change based on Locale. If you are not using US/English date format, change this value.
Jar File Location. This is the full path to the StarTeam jar library AnthillPro uses to retrieve change logs. The full path including the starteamXX.jar file name is required. This is usually found in a StarTeam SDK folder.
Command Path. The location of the stcmd executable. This value can take on a value that changes depending on the agent like
${env\STAR_HOME}\bin.
Each project will have on or more source configurations. These provide a template for a set of code to checkout. Typically, a source configuration is set up for each major concurrent line of development (branch or view). There may also be a template for building from a specific label.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
Project Name. The name of the StarTeam project. A project is the container for one or more views.
View. If AnthillPro is building from a view other than the default, name that view here.
Path. If only a subset of the view should be retrieved and built from, provide that path.
Label Script. Build from a specific label. This could be a hard-coded floating label. Or a dynamic label like
${property:label}passed in at build time.
The first step in using a Subversion repository with AnthillPro is to configure it by following the Repositories link on the System page. The configuration will allow basic information regarding Subversion to be reused by several project workflows. Once configured, the repository will be listed on the Repositories main page.
Once the main repository has been identified, your workflows can then use the Subversion repository. During project creation, associate the project with a specific Subversion repository. See Subversion Source Configuration.
You must have administrative permissions. See Manage Security.
The Subversion Root URL must be available to complete the configuration.
If using the ViewVC integration, see ViewVC.
Go to System > Repositories under the Project Support menu.
On the Repositories page, click the Create New button.
Select Subversion from the drop-down menu and click Set.
On the Main tab, configure repository:
Name the repository.
Description. Give an optional description.
Root URL. Provide the base URL of the repository.
Username. Give the user name to use when accessing the repository.
If using the ViewVC integration, the Username field must be the ViewVC repository name. It is not possible to use ViewVC if properties are set for the Username field. See ViewVC.
Password. Provide the password corresponding to the account specified in the Username field. Select either: No Password, Use Password, or Use Script.
No Password. If no password is associated with AnthillPro's Subversion account, use this option.
Use Password. If a password is associate with AnthillPro's Subversion account, select this potion. Give the password in the Password field and confirm the password.
Use Script (advanced). Give a parameterizable value that will resolve to the password. Use this instead of the Password field if the password will be stored in a secure property resolved at runtime. See Scripting.
Command Path. Provide the location of the svn executable, if not in system path.
Source Viewer. Select the Source Viewer Type from the drop-down menu (if using the ViewVC integration). Otherwise select None. See ViewVC.
If not setting a Repository Trigger or Security, click Set then Done to complete. Otherwise proceed to item 6 to set a trigger or item 8 to set security.
Select the Trigger tab. To either deactivate or delete the repo trigger, click the appropriate button. If the repo trigger is deactivated/deleted, you will need to configure a workflow trigger for every project. See Using Triggers with Subversion.
If not setting Security, click Activate then Done to complete. Otherwise click Activate and proceed to item 8.
Select the Security tab and click the Edit button. Check the appropriate boxes to determine user-role access (See Manage Security), and click Save.
Click Done.
Once the main Subversion repository is identified (see Set Up Subversion Repository), configure the specific repository a workflow uses. During project creation, the originating workflow is first associated with the Subversion repository. Once this is done, the Source Configuration page will automatically pop up. (However, if you choose not to configure the project source at initial creation, you can return to it by selecting the Edit Source link on the Workflow Main page.)
See also Using Triggers with Subversion.
Once Subversion is set up with AnthillPro (see Set Up Subversion Repository), create a project. See Setting Up a Build.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
Working Directory Script. Select the Working Directory Script from the drop-down menu. The working directory is the location where the agent is going to run its commands. For example, if the working directory is
C:\projects\Project_A\every command AnthillPro issues will be from that specific directory.If no Working Directory Script is configured in the job, the script selected here will be used. See Working Directory Scripts.
Directory Offset. Give the sub-directory where this module is to be placed within the working directory. If the root of the working directory is to be used, leave this item blank.
Source URL. Provide the URL of the project source. Note that the Source URL is relative to the selected repository root URL.
Tag. If using tags, give the tag to use for checkout. This may include variables passed to the workflow via
${property:Name}format. See Scripting.Revision. Give the Revision to use for checkout (if any). This may include variables passed to the workflow via
${property:Name}format. See Scripting and Using Triggers with Subversion.Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File paths to exclude from changelog. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.
Click Save.
See also Using Triggers with Subversion.
Subversion (SVN) repository triggers allow you to create a single hook in the Subversion repository that is capable of triggering every workflow using this repository. In the post-commit hook script in your SVN repository, add a check to see that the changed information is on the path to the project. Then use a utility like Wget to generate an HTTP request to the URL specified in the trigger.
By default, AnthillPro activates the Subversion repository trigger when the repository is configured. When configuring an AnthillPro project, the repo trigger is automatically generated for every workflow. Under some conditions, it may be necessary to deactivate the repository trigger for individual workflows. See Ignoring Subversion Repository Trigger.
If using Windows, see also Subversion Post-commit Hook and Windows.
Use a utility such as Wget to generate an HTTP request to the URL specified in the trigger. To build from trunk, it should look something like the following:
if [ -n "$(svnlook changed /data/svn/mycompany/myproject -r $2 | grep
trunk)" ]
then
wget -t 0 https://server/trigger --post-data='triggerId=31&code
=95cde532437151c551cf062bf93c0d12de9209c7'
fiIf building from a branch, change the script to something like:
if [ -n "$(svnlook changed /data/svn/mycompany/myproject -r $2 | grep
branches/june_release)" ]
then
wget -t 0 https://server/trigger --post-data='triggerId=31&code
=cf062bf93c0d12d95cde532437151c551e123456'
fiTo build based on the Subversion revision ID, change the script to:
post-data="code=$CODE&dirs-changed=$DIRSCHANGED&revision-date=$REVISION_DATE&revision-id=$REV"
Additionally, on the workflow source configuration, you will also need to change the Revision field to something similar to the following:
${bsh:PropertyLookup.get("revision-id") == null ? "" : PropertyLookup.get("revision-id")}
In a Windows environment, configuration of the Subversion post-commit hook requires a Wget Windows port (due to Windows shell command restrictions). Subversion hook scripts use the absolute path to the programs because they call the clean Windows PATH variable for the entire environment.
In order to complete the configuration:
Download the Wget Windows port.
Place the Wget Windows port in the hooks directory.
Name the script script.vbs (it can be written as VBScript) and place it in the hooks directory.
Example Subversion Post-commit Hooks Script for Windows:
TRIGGER_URL = "https://localhost:8443/trigger" REPOS = WScript.Arguments.Item(0) REV = WScript.Arguments.Item(1) CODE = "c6ae3e9eeaebb6830aca6e7fb51247b39d410ab3" dq = chr(34) Set oWSH = CreateObject( "WScript.Shell" ) Set nRet = oWSH.Exec( "C:\your\path\to\Subversion\bin\svnlook.exe _ dirs-changed " & REPOS & " -r " & REV) DIRSCHANGED = nRet.StdOut.ReadAll Set nRet2 = oWSH.Exec( "C:\your\path\to\hooks\wget.exe --tries 1 _ --no-check-certificate " & dq & TRIGGER_URL & dq & " --post-data=" & dq & _ "code=" & CODE & "&dirs-changed=" & DIRSCHANGED & dq )
Place a post-commit.bat in the hooks directory.
Because Subversion is unable to natively call the VBScript, the post-commit hook must be invoked from either a .bat or .exe file.
Example post-commit.bat script:
C:\your\path\to\repository\hooks\script.vbs %1 %2
By default, AnthillPro activates the Subversion repository trigger when the repository is configured. When configuring an AnthillPro project, the repo trigger is automatically created and added to every workflow. Under some conditions, it may be necessary to deactivate the repository trigger for individual workflows: It is common for a project to have multiple workflows that must build independently of each other, and in this case the repository trigger may kick off a workflow unnecessarily. For example, a project might have 3 workflows that need to build independently of each other: Workflow A just compiles code; workflow B performs nightly build; and workflow C builds a release candidate. To keep the workflows, which all use the same repository, independently building (i.e., build when you want them to) disable the repository trigger on the workflow and create a workflow trigger (see Use Triggers and Scheduled Builds).
Go to Administration, select the appropriate workflow, and select the Triggers tab. If you can't access this page, that means you don't have the appropriate permissions. Contact your AnthillPro administrator.
Click the Ignore Repository Trigger icon under the Actions menu.
Once the trigger is disabled, the icon will change from green to brown. To enable the trigger for this workflow, simply click the icon again.
Create a workflow trigger. See Use Triggers and Scheduled Builds.
Repeat Items 1 thru 3 for every workflow that will not use the repository trigger.
If you need to build multiple branches of source within the same workflow, you will need to modify SVN Get Changelog step in your build job. This will allow any properties that are passed on the trigger to determine what is built based on the Start Stamp Pattern. Your Stamp should contain the source branch in it. In the example below, the property is named "source":
build-${property:source}-${bsh:BuildLifeLookup.getCurrent().getId()}To use a Synergy repository with AnthillPro, configure it from the Repositories item on the Administration page. The configuration will allow basic information regarding the Synergy repo to be reused by several project workflows. Once configured, the repository will be listed on the Repositories main page and available during source configuration when creating a project.
You must have administrative permissions for the System page. See Manage Security.
The Synergy database path must be available to complete the configuration.
AnthillPro must be set up as a Synergy user.
Go to System > Repositories from the Project Support menu.
On the Repositories page, click the Create New button.
Select Synergy from the drop-down menu and click Set.
Configure repository.
Name the repository.
Description (optional). Provide a description
Username. Enter the user name to use when accessing the repository.
Password. Provide the password corresponding to the account specified in the Username field. Select either: No Password, Use Password, or Use Script.
No Password. If no password is associated with AnthillPro's Synergy account, use this option.
Use Password. If a password is associate with AnthillPro's Synergy account, select this potion. Give the password in the Password field and confirm the password.
Use Script (advanced). Give a parameterizable value that will resolve to the password. Use this instead of the Password field if the password will be stored in a secure property resolved at runtime. See Scripting.
Database path. Enter the path to the Synergy Database (may be a UNC path).
Home Directory. When starting a session, Synergy writes information to the home directory of the user the command is running as. If the user (the AnthillPro agent is running as) has no home directory, you can specify another directory for this information to be written to.
Database Info Directory. This option is only used when using the remote client: i.e., if you check the Use Remote Client box below. If you enter a directory here but do not use the remote client, AnthillPro will ignore this setting, and use the default /tmp/cmm directory.
When starting a session with a remote client, Synergy writes out certain database connection information to the file system. The default directory is /tmp/ccm. If you need it to write to a different directory, specify the directory here.
Role (optional). Enter the role to login with for the provided user name. If no role is specified, AnthillPro will use "build_mgr". Only those with a "build_mgr" role can label and/or create a baseline.
Host (optional). Enter the host name of the machine Synergy is running on.
Maintain Session. Check the box to maintain a single Synergy Session per job. If a Synergy session is slow to establish, checking the box will ensure the job runs correctly.
Use Remote Client. Check the box to remove the client option when starting a Synergy session. If checked, AnthillPro will pass the
-rcflag and remove the client when starting a Synergy session. If you check this box, you will need specify the Database Info Directory above.Command path. Enter the location of the
ccmexecutable (if not in the system path).Date Format. Determine the date format to use when parsing change logs. The default (EEE, MMM dd, yyyy hh:mm:ss a) corresponds to the Java SimpleDateFormat that is output by the Synergy get-changelog command.
Click Set.
Select the Security tab. See Manage Security.
Click Edit, determine permissions, click Save, and then click Done.
Click Done.
Once the main Synergy repository is identified (see Set Up Synergy Repository), configure the specific repository a workflow uses. During project creation, the originating workflow is first associated with the Synergy repository. Once this is done, the Source Configuration page will automatically pop up. (However, if you choose not to configure the project source at initial creation, you can return to it by selecting the Configure, or Edit Source, link under the Source Config menu on the Workflow Main page.)
Once Synergy is set up with AnthillPro (see Set Up Synergy Repository), create a project.
Select the appropriate Synergy repository from the drop-down menu and click Set.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
Project Spec. Give the Project Spec for the Synergy Project. The Project Spec is defined in Synergy, and is required here.
Release. Enter the Synergy Release to use when creating a baseline. If you want to perform a label step, you must give a release here.
Purpose. Enter the synergy purpose to use when creating a baseline. If nothing is given, default is: Integration Testing.
Checkout Strategy. Select a strategy. Either perform a checkout if one does not exist or use an existing checkout when dealing with Synergy Project Specs.
Work Area. Give the Work Area of the Synergy Project Spec to be used.
Working Directory Script. Select the Working Directory Script from the drop-down menu. The working directory is the location where the agent is going to run its commands. For example, if the working directory is
C:\projects\Project_A\every command AnthillPro issues will be from that specific directory.If no Working Directory Script is configured in the job, the script selected here will be used. See Working Directory Scripts.
Reconf. Enter the value to use for a checkout.
Baseline. Give the baseline to checkout from.
Versions. Give the value to use for a checkout.
Checkout Purpose. Enter the purpose for the checkout. For example, Collaborative Development and Insulated Development may be used.
Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File paths to exclude from changelog. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.
Click Save.
The first step in using a TFS repository with AnthillPro is to configure it by following the Repositories link on the System page. The configuration will allow basic information regarding TFS to be reused by several project workflows. Once configured, the repository will be listed on the Repositories main page.
AnthillPro supports both the 2005 and 2008 versions of TFS. Repository set up and source configuration are the same for both.
Once the main repository has been identified, your workflows can then use the TFS repository during workflow source configuration. During project creation, the workflow is associated with a specific TFS repository.
AnthillPro may also be configured to create a TFS WorkItem, add comments, publish a WorkItem report, and Resolve WorkItems. See Team Foundation Server (TFS) Project Tracking.
You must have administrative permissions. See Manage Security.
The TFS URL must be available to complete the configuration.
The TFS client must be installed on the same build machine as the agent so that AnthillPro can run TFS commands.
Go to System > Repositories from the Project Support menu.
On the Repositories page, click the Create New button.
Select TFS from the drop-down menu and click Set.
Configure repository:
Name the repository. This is the name AnthillPro will use to identify this repository.
Description. Give an optional description.
TFS Server URL. Provide the repository URL.
TFS Version. From the drop-down menu, select the version of TFS you are using.
Command Path. Provide the absolute path to the tf executables if not in the system path.
Click Set.
Select the Security tab. See Manage Security.
Click Edit, determine permissions, click Save, and then click Done.
Click Done.
To set up a repository trigger, see Using Triggers with TFS.
Once the main TFS repository is identified (see Set Up TFS Repository), configure the specific repository a workflow uses. During project creation, the originating workflow is first associated with the TFS repository. Once this is done, the Source Configuration page will automatically pop up. (However, if you choose not to configure the project source at initial creation, you can return to it by selecting the Configure, or Edit Source, link under the Source Config menu on the Workflow Main page.)
Once TFS is set up with AnthillPro (see Set Up TFS Repository), create a project.
Select the appropriate TFS repository from the drop-down menu and click Set.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
Repository. Select the repository from the drop-down menu. By default, AnthillPro will use the repository selected in the previous step. To change TFS repositories, select a different repository from the drop-down menu. If only one repo is listed, then only one TFS repository is configured. If changing repositories, make sure to reconfigure all remaining fields.
Working Directory Script. Select the Working Directory Script from the drop-down menu. The working directory is the location where the agent is going to run its commands. For example, if the working directory is
C:\projects\Project_A\every command AnthillPro issues will be from that specific directory.If no Working Directory Script is configured in the job, the script selected here will be used. See Working Directory Scripts.
Workspace Name. Give the name of the TFS workspace to use. A property (via
${property:Name}format) or short script may be used here.Source URL. Give the project-source URL, relative to the selected repository root URL. A property (via
${property:Name}format) or short script may be used here. For example, you can script the SourcePath Module.Tag. If checking out from a tag, give it here. This may include variables passed to the workflow via
${property:Name}format, or may be hard coded.Revision. Give the Revision to use for checkout. This may include variables passed to the workflow via
${property:Name}format, or may be hard coded.Directory Offset. Give the directory to retrieve files to (i.e., checkout destination), if the TFS default directory structure is not desired. This may include variables passed to the workflow via
${property:Name}format.Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File paths to exclude from changelog. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.
Click Save.
If adding additional sources to the workflow is necessary, set up is similar to that of the initial source configuration (see TFS Source Configuration). When adding additional sources, all URLs are relative to the root URL.
Once an additional source has been added to the workflow, it will appear on the workflow Main tab under the Source Config menu, and may be edited or deleted using the icons under the Actions menu.
To add an additional source to an existing workflow:
Go to Administration and select the workflow that an additional source is to be added to.
On the workflow Main page, select the Add Additional Source link under the Source Config menu.
Configure source:
Source URL. Give the project-source URL, relative to the selected repository root URL.
Tag. If checking out from a tag, give it here. This may include variables passed to the workflow via
${property:Name}format, or may be hard coded.Revision. Give the Revision to use for checkout. This may include variables passed to the workflow via
${property:Name}format, or may be hard coded.
Click Save.
TFS repository triggers allow you to create a single hook in the repository that is capable of triggering every workflow using this repository. By default, AnthillPro activates the TFS repository trigger when the repository is configured. When configuring an AnthillPro project, the repo trigger is automatically generated for every workflow. Under some conditions, it may be necessary to deactivate the repository trigger for individual workflows. See Ignoring TFS Repository Trigger.
Once the TFS repository is set up, click the Trigger tab.
Copy the TFS command that AnthillPro automatically generated.
Replace the
<serverName>with the name of your TFS Server.Go to your TFS Setup directory and execute the command. This will setup a SOAP notification to AnthillPro on check-in that contains information about changes.
You can either deactivate of delete the trigger. Only one repository trigger may be active at any one time. If you deactivate a trigger, you can return to it and reactivate it; if you delete a trigger, you can create a new one by repeating the previous steps.
See also Ignoring TFS Repository Trigger.
By default, AnthillPro activates the TFS repository trigger when the repository is configured. When configuring an AnthillPro project, the repo trigger is automatically created and added to every workflow. Under some conditions, it may be necessary to deactivate the repository trigger for individual workflows: It is common for a project to have multiple workflows that must build independently of each other, and in this case the repository trigger may kick off a workflow unnecessarily. For example, a project might have 3 workflows that need to build independently of each other: Workflow A just compiles code; workflow B performs nightly build; and workflow C builds a release candidate. To keep the workflows, which all use the same repository, independently building (i.e., build when you want them to) disable the repository trigger on the workflow and create a workflow trigger (see Use Triggers and Scheduled Builds).
Go to Administration, select the appropriate workflow, and select the Triggers tab. If you can't access this page, that means you don't have the appropriate permissions. Contact your AnthillPro administrator.
Click the Ignore Repository Trigger icon under the Actions menu.
Once the trigger is disabled, the icon will change from green to brown. To enable the trigger for this workflow, simply click the icon again.
Create a workflow trigger. See Use Triggers and Scheduled Builds.
Repeat Items 1 thru 3 for every workflow that will not use the repository trigger.
To use a SourceGear Vault repository with AnthillPro, configure it from the Repositories item on the Administration page. The configuration will allow basic information regarding the Vault server to be reused by several project workflows. Once configured, the repository will be listed on the Repositories main page.
You must have administrative permissions. See Manage Security.
AnthillPro must be set up as a Vault user.
The command path of the executable and the host name must be available.
Go to System > Repositories from the Project Support menu.
On the Repositories page, click the Create New button.
Select Vault from the drop-down menu and click Set.
Configure repository:
Name the repository.
Description. Give an optional description.
Host. Provide the name of the host machine.
Repository. Provide the name of the Vault repository.
Username. Give the user name AnthillPro will use to access the repository.
Password. Provide the password corresponding to the account specified in the Username field. Select either: Set Password or Use Script.
Set Password. If a password is associate with AnthillPro's Vault account, select this potion. Give the password in the Password field and confirm the password.
Use Script (advanced). Give a parameterizable value that will resolve to the password. Use this instead of the Password field if the password will be stored in a secure property resolved at runtime. See Scripting.
Use SSL. Check the box to use SSL when AnthillPro connects to the repository.
Command Path. Provide the absolute path to the executable if not in the system path.
Click Set.
Select the Security tab. See Manage Security.
Click Edit, determine permissions, click Save, and then click Done.
Click Done.
The ViewVC integrations provides CVS and Subversion users access to the ViewVC browser interface from within the AnthillPro UI. Once configured, the integration allows users to view the ViewVC navigable directory, revision, and change log listings, including specific versions of files. See ViewVC and CVS or ViewVC and Subversion.
The ViewVC integrations provides CVS (and CVSNT) users access to the ViewVC browser interface from within the AnthillPro UI. Once configured, the integration allows users to view the ViewVC navigable directory, revision, and change log listings, including specific versions of files.
You must have AnthillPro administrative privileges to configure the integration. See Manage Security.
The CVS repository must be correctly configured. See CVS.
The ViewVC URL and repository name must be available.
A project must be active in AnthillPro.
Configure AnthillPro to integrate with ViewVC. Links to ViewVC will appear when this is configured.
Historic information is not available due to the nature of the AnthillPro 3.4 integration. However, the integration will allow you to view all changes, etc., made after AnthillPro 3.5 is installed.
Go to System > ViewVC under the Integration menu.
On the ViewVC page, click Edit.
Give the ViewVC Server URL, click Set then Done.
Go to System > Repositories from the Project Support menu.
Select the CVS repository (from Item Four) from the Repositories list. This item requires that the CVS repository is already configured. See CVS.
On the Main tab, click Edit and select ViewVC from the drop-down menu (of the Source Viewer item).
To view the repository, follow the Repository URL link (of the Source Viewer item).
Click Set then Done.
Once ViewVC has been set up (see Set up ViewVC and CVS), AnthillPro makes Source URL and Tags URL indexes available via ViewVC. Revision information, including detailed information on each file changed, is available on the Dashboard Changes tab.
To view Source URL and Tags URL via ViewVC:
Go to Administration and select the appropriate workflow.
On the workflow Main tab, follow the Edit Source link in the Source Configuration menu.
For the Module Name item, click the Source URL link and ViewVC will open in a new window.
To view revision and file changes via ViewVC:
Go to Dashboard > Changes tab.
Select the change number link and ViewVC will open the revision in a new window.
Expand the Change number and select the View Files link. Select an individual change and ViewVC will open a view of the actual change.
The ViewVC integrations provides Subversion users access to the ViewVC browser interface from within the AnthillPro UI. Once configured, the integration allows users to view the ViewVC navigable directory, revision, and change log listings, including specific versions of files.
You must have AnthillPro administrative privileges to configure the integration. See Manage Security.
The Subversion repository must be correctly configured. See Subversion.
The ViewVC URL and repository name must be available.
A project must be active in AnthillPro.
Configure AnthillPro to integrate with ViewVC. Links to ViewVC will appear when this is configured. In order to use ViewVC integration, the Source Configuration Username field (see Subversion) must be the ViewVC repository name. It is not possible to use ViewVC if properties are set for the Username field.
Go to System > ViewVC under the Integration menu.
On the ViewVC page, click Edit.
Give the ViewVC Server URL, click Set then Done.
Go to System > Repositories from the Project Support menu.
Select the Subversion repository (from Item Four) from the Repositories list. This item requires that the Subversion repository is already configured. See Subversion.
On the Main tab, click Edit and select ViewVC from the drop-down menu (of the Source Viewer item).
To view the repository, follow the Repository URL link (of the Source Viewer item).
Click Set then Done.
Once ViewVC has been set up (see Set up ViewVC and Subversion), AnthillPro makes Source URL and Tags URL indexes available via ViewVC. Revision information, including detailed information on each file changed, is available on the Dashboard Changes tab.
To view Source URL and Tags URL via ViewVC:
Go to Administration and select the appropriate workflow.
On the workflow Main tab, follow the Edit Source link on the Source Configuration menu.
For the Source URL item, click the Source URL link and ViewVC will open in a new window.
For the Tags URL item, click the Tags URL link and ViewVC will open in a new window.
To view revision and file changes via ViewVC:
Go to Dashboard and select the Changes tab.
Select the change number link and ViewVC will open the revision in a new window.
Expand the Change number and select the View Files link. Select an individual change and ViewVC will open a view of the actual change.
To use a Microsoft Visual SourceSafe (VSS) repository with AnthillPro, configure it by following the Repositories link on the System page. The configuration will allow basic information regarding VSS to be reused by several project workflows. Once configured, the repository will be listed on the Repositories main page.
After the main repository has been identified, your workflows can then use the VSS repository. During project creation, associate the project workflow with a specific VSS repository and create a build job that includes the VSS job steps (see VSS Source Configuration). If you use the Job Wizard, AnthillPro will automatically add these steps during job configuration; however, if you create your own job, you will need to add these steps yourself.
You must have administrative permissions. See Manage Security.
The VSS root must be available to complete the configuration. The root must include the path to the repository (where the srcsafe.ini file resides). This can be either a local path or a UNC path to a shared drive and must end with a \ to signify a directory.
Go to System > Repositories from the Project Support menu.
On the Repositories page, click the Create New button.
Select VSS from the drop-down menu and click Set.
Configure repository:
Name the repository.
Description. Give an optional description.
Root. Provide the path to the repository (where the srcsafe.ini file resides). This could be either a local path or a UNC path to a shared drive and must end with a \ to signify a directory.
Username. Give the user name to use for AnthillPro to access the repository.
Password. Provide the password corresponding to the account specified in the Username field. Select either: No Password, Use Password, or Use Script.
No Password. If no password is associated with AnthillPro's VSS account, use this option.
Use Password. If a password is associate with AnthillPro's VSS account, select this potion. Give the password in the Password field and confirm the password.
Use Script (advanced). Give a parameterizable value that will resolve to the password. Use this instead of the Password field if the password will be stored in a secure property resolved at runtime. See Scripting.
Command Path. Provide the absolute path to the ss executables if not in the system path.
Click Set.
Select the Security tab. See Manage Security.
Click Edit, determine permissions, click Save, and then click Done.
Click Done.
Once the main VSS repository is identified (see Set Up VSS Repository), configure the specific source a workflow uses. During project creation, the originating workflow is first associated with the VSS repository. Once this is done, the Source Configuration page will automatically pop up. (However, if you choose not to configure the project source at initial creation, you can return to it by selecting the Edit Source link on the Workflow Main page.)
Once Git is set up with AnthillPro (see Set Up Git Repository), create a project.
Go to the originating workflow that was created as part of the project creation process. If you have not created an originating workflow yet, see Create a New Workflow before continuing. Configure the source on the workflow:
Repository. This field is automatically populated by AnthillPro.
Working Directory Script. Select the Working Directory Script from the drop-down menu. The working directory is the location where the agent is going to run its commands. For example, if the working directory is
C:\projects\Project_A\every command AnthillPro issues will be from that specific directory.If no Working Directory Script is configured in the job, the script selected here will be used. See Working Directory Scripts.
Project/Branch. Give the name of the project to use in the form of
$/project. If you want to use a branch or module, use something like$/project/path/to/branch.Label Script. Give the label to use, if using labels.
Users to exclude from changelog. To exclude any users from the changelog, input them here. Each excluded user must be input on a separate line. Note that user names are case sensitive.
File paths to exclude from changelog. If you need to exclude file paths from the changelog, list them here, each on a separate line. Each path must be proceeded by + or - to include/exclude it from the changelog.
The following wild cards may be used:
for any subdirectory:
**/ -for any number of any characters except \ and /:
* -for any single character / including \ and / Changelog file paths containing drive letter or any prefixes:
? -
Make sure to include the * at the beginning of the path.
Example exclude paths:
-**/abc/**/*Except for:+**/abc/*.html. This will exclude everything under the abc directory except for the HTML files in it.
Click Save.