Dependent Build
In TeamCity one build configuration can depend on one or more configurations. Two types of dependencies can be specified:
Artifact dependency is just a way to get artifacts produced by one build in another. Without corresponding Snapshot dependency they are mainly used when the build configurations are not related in terms of sources. For example one build provides a reusable component for others. Snapshot dependency influences the way builds are processed and implies that the builds are deeply related with one build being a logic part of another one.
Snapshot Dependency
Snapshot Dependency is a powerful concept that allows to express dependencies between the build configurations on the source level in TeamCity. See also Build Dependencies Setup.
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;
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 after adding builds to the queue. At this time all the VCS roots of the chain are checked for changes and the current revision is fixed in the builds;
build does not start until all it's snapshot dependencies are ready;
if some of the build configurations already have a started 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. This procedure can be performed several times, because while builds of the chain remain in the queue new builds may start and finish;
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 from the same-sources build.
Let's consider an example to illustrate how snapshot dependencies work.
Let's assume that we have two build configurations, A and B, and configuration A has snapshot dependency on configuration B.
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 starts first and build A will wait in the queue till build B is finished (Snapshot Dependencies).
When the builds B and A are added in the queue TeamCity adjusts the sources to include in these builds. All builds will be run with sources taken on the moment the builds were added to the queue.
If the build configurations connected with snapshot dependency Configuring 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.
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 any additional options. For snapshot dependency options refer to the Snapshot Dependencies page.
Depending on the dependencies topology builds can run sequentially or 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.
See also related "Trigger on changes in snapshot dependencies" Configuring VCS Triggers of a VCS trigger and "Show changes from snapshot dependencies" check box on "Version Control Settings" configuration section.
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 Artifact Dependencies page. If for some reason you need to store artifact dependency information together with your codebase and not in TeamCity, you can configure Artifact Dependencies 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 Clean-Up 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 Clean-Up page.