The idea of artifact dependencies in TeamCity is very simple: download the artifacts produced by an other build before the current one begins. In order to address these scenarios, TeamCity provides two ways to connect dependent build configurations and their outcomes: artifact and snapshot dependencies. Secondly, snapshot Maven dependencies provide their own set of challenges covered in the previous blog post, making it harder to ensure correct snapshot dependency is used in a chain of builds. For starters, you may not be developing in Java or perhaps your build tool is not providing built-in integration with Maven repositories, as is the case with Ant (or its Gant and NAnt spin-offs), SCons, Rake or MSBuild. While Maven-based dependencies management and artifact repositories are very common and widespread in Java, there are cases where you may still find them insufficient or inadequate for your needs. This is the second post, which covers artifact and snapshot dependencies provided by TeamCity and the third and final part will cover the artifact and build dependencies provided by TeamCity Artifactory plugin. The first post explored Maven snapshot and release dependencies. Having this in mind I’ve decided to explore each solution in its own blog post, setting a goal of providing enough information so that people can choose what works best. Some of the names mentioned above seem not to be established enough while others may require a discussion about their usage patterns. TeamCity users who are familiar with artifact and snapshot dependencies may not know that adding an Artifactory plugin allows them to use artifact and build dependencies as well, on top of those provided by TeamCity. Maven and Gradle users who are familiar with release and snapshot dependencies may not know about TeamCity snapshot dependencies or assume they’re somehow related to Maven (which isn’t true). Various build tools approach this subject from different perspectives contributing various solutions, each with its own strengths and weaknesses. The subject of build dependencies is neither a trivial nor a minor one. Technorati tags: TeamCity, JetBrains, Java. In the latest TeamCity 3.0 EAP versions we provide a possibility to view the info on the build artifacts were used to create the build on the Build Results page: You need to download the Ivy Dependency manager from and follow the steps described in TeamCity online reference. The dependencies are specified in the ivy.xml configuration file, you can put the file in your CMS repository and safely test changes in this file when running personal builds. Since TeamCity itself acts like an Ivy repository it allows you to download the artifacts using Ivy tasks or Ivy tool from the command line. The artifact dependencies are set up when you create or edit the build configuration: It’s also possible to specify the destination directory where the artifacts are downloaded when the build is started and configure whether to clean the catalogue before creating builds and downloading artifacts to avoid artifacts clutter. One or several artifacts paths can be specified. In the artifacts paths you can use regular expressions or file patters. last finished build (can be useful when integrating with changes third-party libraries).
When creating new builds, it’s possible to use the artifacts of: artifact dependencies and provides dependent builds triggering. Since version 2.0 TeamCity allows to specify the dependencies between the results of the builds of the build configurations, i.e.
0 kommentar(er)
