Configuring Artifact Dependencies Using Web UI
To add dependencies to a build configuration:
- When creating/editing build configuration, open Dependencies page.
- Click the Add new artifact dependency link and specify the following settings:
| Depend on
| Specify the build configuration that the current build configuration should depend on.
| Get artifacts from
|| Specify the type of build, from which the artifacts should be taken: last successful build, last pinned build, last finished build, build from the same chain (this option is useful when you have a snapshot dependency and want to obtain artifacts from a build with the same sources), build with specific build number or last finished build with specified tag.
- When selecting the build configuration, take your clean-up policy settings into account. Builds are cleaned and deleted on a regular basis, thus the build configuration could become dependent on a non-existent build. When artifacts are taken from a build with a specific number, then the specific build will not be deleted during clean-up.
- If both dependency by sources and dependency by artifacts on a last finished build are configured for a build configuration, then artifacts will be taken from the build with the same sources.
| Build number
|| This field appears, if you have selected build with specific build number in the Get artifacts from list. Specify here the exact build number of the artifact.
| Build tag
|| This field appears, if you have selected last finished build with specified tag in the Get artifacts from list. Specify here the tag of the build which artifacts should be used. When resolving dependency, TeamCity will look for the last successful build with given tag and use its artifacts.
| Artifacts Rules
|| Newline-delimited set of rules. Each rule must have following syntax:
Each rule specifies the files to be downloaded form the "source" build. The SourcePath should be relative to the artifacts directory of the "source" build. The path can either identify a specific file, directory, or use wildcards to match multiple files. Ant-like wildcards are supported.
Downloaded artifacts will keep the "source" directory structure starting with the first * or ?.
DestinationPath specifies the destination directory on the agent where downloaded artifacts should be placed. If the path is relative, it will be resolved against the build checkout directory. If needed, the destination directories can be cleaned before downloading artifacts. If destination path is empty, artifacts will be downloaded directly to checkout root.
- Use a/b/**=>lib to download all files from a/b directory of the source build to the lib directory. If there is a a/b/c/file.txt file in the source build artifacts, it will be downloaded into the file lib/c/file.txt.
- At the same time, artifact dependency */.txt=>lib will preserve the directories structure: the a/b/c/file.txt file from source build artifacts will be downloaded to lib/a/b/c/file.txt.
ArchivePath is used to extract downloaded compressed artifacts. Zip, jar, tar and tar.gz are supported. ArchivePath follows general rules for SourcePath: ant-like wildcards are allowed, the files matched inside the archive will be placed in the directory corresponding to the first wildcard match (relative to destination path)
For example: release.zip!*.dll command will extract all .dll files residing in the root of release.zip artifact.
Archive processing examples:
- release-*.zip!*.dll=>dlls will extract *.dll from all archives matched release-*.zip pattern to the dlls directory.
- a.zip!**=>destination will unpack entire archive saving path information.
- a.zip!a/b/c/*/.dll=>dlls will extract all .dll files from a/b/c and its subdirectories, into the dlls directory, without a/b/c prefix.
+: and -: can be used to include or exclude specific files from download or unpacking. As +: prefix can be ommited: rules are inclusive by default, and at least one inclusive rule is required. Order of rules is unimportant. For each artifact, most specific (with longest prefix before first wilcard symbol) rule is applied. When excluding a file, DestinationPath is ignored: file wont be downloaded at all. Files can also be excluded from archive unpacking. Set of rules applied to archive content is determined by set of rules matched by archive itself.
Exclusive patterns examples:
Will download all *.txt files from all directories, excluding exclude.txt from bad directory
Will download and unpack all dlls from release-*.zip files to dlls directory. Bad.dll file from release-0.0.1.zip will be skipped
Will download all artifacts to target directory. Will not download anything from excl directory, but one file, called must_have.txt
|Click the icon to invoke the Artifact Browser. TeamCity will try to locate artifacts according to specified settings and show then in a tree. Select required in the tree and TeamCity will place the paths to them into the input field.|
Artifacts placed under .teamcity directory are considered hidden. These artifacts are ignored by wildcards by default.
If you want to include files from .teamcity directory for any purpose, be sure to add artifact path starting with .teamcity explicitly.
Example of accessing hidden artifacts:
| Clean destination paths before downloading artifacts
|| Check this option to delete the content of the destination directories before copying artifacts. It will be applied to all inclusive rules
At any point you can launch a build with custom artifact dependencies - read more.
Configuring Artifact Dependencies Using Ant Build Script
This section describes how to download TeamCity build artifacts inside the build script. These instructions can also be used to download artifacts from outside of TeamCity.
For handling artifact dependencies between the builds this solution is more complicated then configuring dependencies in the TeamCity UI but allows for greater flexibility. For example, managing dependencies this way will allow you to start a personal build and verify that your build is still compatible with dependencies.
To configure dependencies via Ant build script:
1. Download Ivy.
2. Add Ivy to the classpath of your build.
3. Create ivyconf.xml file that contains some meta information about TeamCity repository. This file should have the following content:
4. Replace YOUR_TEAMCITY_HOST_NAME with the host name of your TeamCity server.
5. Place ivyconf.xml in the directory where your build.xml will be running.
6. In the same directory create ivy.xml file in which define which artifacts should be downloaded and where to put them, for example:
- YOUR_ORGANIZATION should be replaced with the name of your organization.
- YOUR_MODULE should be replaced with the name of your project or module where artifacts will be used.
- BUILD_CONFIGURATION_ID should be replaced with id of the build configuration from where artifacts are downloaded. You can obtain this id from the links in your TeamCity server (you should take value of buildTypeId parameter). e.g. bt20
- BUILD_REVISION can be either build number or one of the following strings:
- ARTIFACT_FILE_NAME_WITHOUT_EXTENSION file name or regular expression of the artifact without extension part.
- ARTIFACT_FILE_NAME_EXTENSION extension part of the artifact file name.
7. Modify your build.xml file and add tasks for downloading artifacts, for example (applicable for Ant 1.6 and later):
|Please note that among ivy commons-httpclient, commons-logging and commons-codec should be in classpath of Ivy tasks.|
Artifacts repository is protected by a basic authentication. To access the artifacts, you need to provide credentials to the <ivy:configure/> task. For example:
where TEAMCITY_HOST is hostname or IP address of your TeamCity server (without port and servlet context).
As USER_ID/PASSWORD you can use either username/password of a regular TeamCity user (the user should have corresponding permissions to access artifacts of the source build configuration) or system properties teamcity.auth.userId/teamcity.auth.password.
The properties teamcity.auth.userId/teamcity.auth.password store automatically generated build-unique values whose only intended use is artifacts downloading within the build script. The values are valid only during the time the build is running. Using the properties is preferable to using real user credentials since it allows the server to track artifacts downloaded by your build. If the artifacts were downloaded by the build configuration artifact dependencies or using the supplied properties, the specific artifacts used by the build will be displayed at the Dependencies tab on the build results page. In addition, the builds which were used to get the artifacts from will not be cleaned up by the clean-up process much like the pinned builds.