Dependent Build

Skip to end of metadata
Go to start of metadata
You are viewing documentation of TeamCity 6.5.x, which is not the most recent released version of TeamCity. Please refer to the listing to choose another version.
Search

Searching TeamCity 6.5.x Documentation

Table of Contents

In TeamCity one build configuration can depend on one or more configurations. Two types of dependencies can be specified:

Snapshot Dependency

Snapshot Dependency is a powerful concept that allows to express dependencies between the build configurations on the source level in TeamCity.

A snapshot dependency from build configuration A to build configuration B enforces that each build of A has a "suitable" build of B so that both builds use the same sources snapshot (used sources revisions correspond to the same moment).

Snapshot dependency alters the builds behavior in the following way:

  • when a build is queued, also queued are the builds from all the Build Configurations it snapshot-depends on;
  • build does not start until all it's snapshot dependencies are ready;
  • when a first build in the the build chain is ready to start, changes are checked for the entire build chain. If some of the build configurations already have a finished build with matching changes and the snapshot dependency has option "Do not run new build if there is a suitable one" ON, the queued matching builds are not run and are dropped.
  • all builds linked via snapshot dependencies are started by TeamCity with explicit specification of the sources revision. The revision is calculated so that it corresponds to the same moment in time (for the same VCS root it is the same revision number). For a queued build chain (all builds linked with snapshot dependency), the revision to use is determined upon the start of the first build in the chain. At this time all the VCS roots of the chain are checked for changes and the current revision is fixed in the builds.
  • if there is a snapshot dependency and artifact dependency on the Build from the same chain pointing to the same build configuration, TeamCity ensures that artifacts are downloaded form the same-sources build.

Let's consider an example to illustrate how snapshot dependencies work.

Let's assume that we have two build configuration, A and B, and configuration A has snapshot dependency on configuration B.

  1. When a build of configuration A is triggered, it automatically triggers a build of configuration B, and both builds will be placed into the Build Queue. Build B should start first and build A will wait in the queue till the B is finished (if no other specific options are set)
  2. When the build B starts to run on the agent, TeamCity adjusts the sources to include in the build A at this exact moment. All builds will be run with sources taken on the moment the build B started to run on a build agent.
    If the build configurations connected with snapshot dependency share the same set of VCS roots, all builds will run on the same sources. Otherwise, if the VCS roots are different, changes in the VCS will correspond to the same moment in time.
  3. When the build B has finished and if it finished successfully, then TeamCity will start to run build A.
    Please note, that the changes to be included in the build A could become not the latest ones to the moment of build start to run. In this case build A becomes a History Build

The above example shows the core basics of the snapshot dependencies, straight forward process, without additional options. For snapshot dependency options refer to the Snapshot Dependencies page.

If a build has snapshot dependencies on several builds, the snapshot will be taken at the moment the first build of the whole set (chain) starts to run on a build agent. Depending on the dependencies topology builds could be subsequent or can be started in parallel.

Two or more builds connected by snapshot dependencies form the Build Chain.
By default, TeamCity preserves builds that are a part of a chain from clean-up, but a user can switch off the option. Refer to the Clean-Up description for more details.

Artifact Dependency

Artifact Dependencies provide you with a convenient means to use output (artifacts) of one build in another build. When an artifact dependency is configured, the necessary artifacts are downloaded to the agent before the build starts. You can then review what artifacts were used in a build or what build used artifacts of the current build on a Dependencies tab of build results.

To create and configure an artifact dependency use the Dependencies page. If for some reason you need to store artifact dependency information together with your codebase and not in TeamCity, you can configure Ivy Ant tasks to get the artifacts in your build script.

Please note that if both snapshot dependency and artifact dependency are configured for the same build configuration, in order to take artifacts from the build with the same sources Build from the same chain option must be selected in artifact dependency.
Notes on Cleaning Up Artifacts
Artifacts may not be cleaned if they were downloaded by other builds and these builds are not yet cleaned up. For a build configuration with configured artifact dependencies you can specify whether artifacts downloaded by this configuration from other builds can be cleaned or not. This setting is available on the cleanup policies page.



See also:

Concepts: Build Artifact
Administrator's Guide: Configuring Dependencies

Labels:

dependent dependent Delete
artifact artifact Delete
build build Delete
snapshot snapshot Delete
Enter labels to add to this page:
Wait Image 
Looking for a label? Just start typing.