Skip to end of metadata
Go to start of metadata
Table of Contents
Expand all   Collapse all

Before You Begin

Please make sure you read the general information about Artifactory's Build Integration before reading the TeamCity-specific documentation.

Release Management with the TeamCity Artifactory Plugin

Version 2.1.0 of the plugin introduces powerful Release Management and Promotion capabilities.

Overview

The TeamCity Artifactory plugin brings CI Build Integration to TeamCity users. This allows you to capture information about deployed artifacts, resolved dependencies and environment data associated with TeamCity build runs.  There is also full traceability for your builds.

Build Integration also takes care of deploying your artifacts to Artifactory efficiently.

 You can read more about the concept of Build Integration, BuildInfo and how it is used in Artifactory here.

Support for multiple Build Runner types

The TeamCity Artifactory plugin supports almost all build runner types, including: Maven2/3, Ivy/Ant (with Ivy modules support), Gradle , NAnt, MSBuild, FxCop and Ipr.

Installing the Plugin

Requirements

Some features of the plugin only run on the recent versions of Artifactory and TeamCity.

To make the most of the plugin, the recommended requirements are:

  • Artifactory 2.2.5 or later.
  • JetBrains TeamCity 5.1.3 or later.

Installation

Download the version of the plugin according to the compatibility matrix below:

Plugins are deployed to TeamCity by placing the packaged plugin into the $TEAMCITY_USER_HOME/.BuildServer/plugins folder and restarting TeamCity.

NOTE! that if you have an older version of the plugin, make sure to remove it.

Compatibility Matrix

Artifactory plugin version

TeamCity version

Artifactory version

1.0

5.1

2.2.4

1.0.1

5.1.1

2.2.5+

1.1.1 - 1.1.2

5.1.3

2.3.0+

1.1.3

5.1.5

2.3.0+

2.0.0

6.0+

2.3.0+

2.0.1

6.0+

2.3.0+

2.1.0

6.5+

2.3.4+

2.1.1

6.5+

2.3.4+

2.1.2

6.5.5+

2.3.4+

2.1.36.5.5+2.6.0
2.1.47.1+2.6.0+

Configuration

To use the TeamCity Artifactory plugin you must first configure your Artifactory server(s) in TeamCity's server configuration. You can then set up a project build runner to deploy artifacts and Build Info to a repository on one of the configured Artifactory servers.

Configuring System-wide Artifactory Server(s)

To make Artifactory servers globally available to project-runner configurations, they must be defined in Administration->Server Configuration->Artifactory.

Click on "Create new Artifactory server configuration" and fill in the URL of the Artifactory server.

Deployer credentials can be set at the global level for all builds. Deploy credentials can be set or overridden at a project build level.

Resolving repository username and password is optional and only used when querying Artifactory's REST API for a list of configured repositories (credentials are only required if the target instance does not allow anonymous access).

Configuring Project-specific Runners

Editing Project-specific Configuration

To set up a project runner to deploy build info and artifacts to Artifactory go to Administration->$PROJECT_NAME->$BUILD_NAME->Edit->Runner (Step 3)->Deploy artifacts to Artifactory.

When selecting an Artifactory server URL, the server is queried for a list of configured repositories (using the credentials in the server configuration, if configured). This populates the "Target Repository" combobox with a list of target repositories to deploy to.

If the repository list remains empty, ensure the specified Artifactory server URL, credentials and proxy information (if provided) are valid.

Any information about communication errors that might occur can be found in the TeamCity server logs. 

  • The 'Deploy Maven Artifacts' option is only available when using a 'Maven2' Build Runner.
Running License Checks

Use the Artifactory Pro License Control feature to discover and handle third party dependency licensing issues as part of the build.

Check the 'Run License Checks' checkbox if you want Artifactory to scan and check the licenses of all dependencies used by this build.

If you want to inform selected users about any license violations detected while scanning, enter a list of email addresses in the notification recipients text box.

Advanced Options

In addition, you have more advanced options:

  • The 'Published Artifacts' area allows you to specify which artifact files produced by the build are published to Artifactory. At the end of the build the plugin locates artifacts in the build's checkout directory according to the specified artifact patterns and publishes them to Artifactory to one or more locations, optionally applying mapping for the target path of each deployed artifact. The pattern and mapping syntax for Published Artifacts is similar to the one used by TeamCity for Build Artifacts.
  • The 'Downloaded Artifacts' area lets you specify dependency patterns for published artifacts that should be downloaded from Artifactory before the build is run. You can have detailed control over which artifacts are resolved and downloaded by using query-based resolution, adding to your artifact paths a query with the properties that the artifact should have before it can be downloaded. For further information read here about Resolution by Properties.

As of version 2.1.4, the above configuration is not backward compatible and you may need to re-save the builds configuration for them to run properly.

Attaching Searchable Parameters to Build-Info and to Published Artifacts

Under Administration->$PROJECT_NAME->$BUILD_NAME->Edit->Runner (Step 6)->Properties and Environment Variables, it is possible to define parameters to be attached to the build-info and produced artifacts.

To define a parameter click on the "Add new property" or "Add new variable" buttons (both system properties and environment variables are supported).

Available parameter types:

  • buildInfo.property.* - All properties starting with this prefix are added to the root properties of the build-info
  • artifactory.deploy.* - All properties starting with this prefix are attached to any deployed produced artifacts

It is also possible to point the plugin to a properties file containing the aforementioned properties.

To point to such a file, define a property by the name buildInfoConfig.propertiesFile and set its value to the absolute path of the properties file.

The given path and file should be present on the machine running the build agent - not the server!.



Viewing Project-specific Configuration

Existing project configuration can be viewed from Projects->$PROJECT_NAME->$BUILD_NAME->Settings->Runner settings:

Running a Build with the Artifactory Plugin

Once you have completed setting up a project runner you can run a project build. The Artifactory plugin takes effect at the end of the build and:

  1. For all build runner types - Publishes the specified Published Artifacts to the selected target repository and applies proper path mappings.
  2. For Maven or Ivy/Ant build runner - Deploys all artifacts to the selected target repository in one go (as opposed to the deploy at the end of each module build, used by Maven and Ivy).
  3. Deploys the Artifactory BuildInfo to Artifactory, providing full traceability of the build in Artifactory, with links back to the build in TeamCity.

You can also link directly to the information in Artifactory from a build run view:

Triggering Builds in Reaction to Changes in Artifactory

The plugin allows you to set a new type of trigger that periodically polls a path in Artifactory, a folder or an individual file.  Whenever a change is detected to this path, for example new artifacts have been deployed, the TeamCity build is triggered.

This feature can only be used with the Artifactory Pro Power Pack.

To configure a new build trigger, first select the Artifactory Build Trigger from Administration->$PROJECT_NAME->$BUILD_NAME->Edit->Build Triggering:

Select the server, repository and paths in the repository for which you would like to automatically trigger a build following a change in the item content.

Complete the username and a password fields of a valid deployer.  

NOTE! that the user must have deploy rights on any local repository).


Narrow down the scope for scanning

When scanning a remote folder for changes, Artifactory has to traverse the folder content and decide if any content has changed. For deep folders this traversal can become quite expensive.

Therefore, it is recommended to keep the scanning scope to a minimum.

Proxy Configuration

Currently, TeamCity does not provide a global point of proxy configuration; so where the target Artifactory server must be accessed via a proxy, proxy configuration can be achieved by setting the following properties inside the $TEAMCITY_USER_HOME/.BuildServer/config/internal.properties file.

License

The TeamCity Artifactory plugin is available under the Apache v2 License.

Watch the Screencast

To see the Teamcity plugin in action you can watch the short demo screencast below.

Changelog

2.1.4 (21 Aug 2012)

  1. Compatible with TeamCity7.1.
  2. Bug Fixes 

2.1.3 (30 May 2012)

  1. Compatible with TeamCity7.
  2. Support 'Perforce' in release management.
  3. Support multiple deploy targets for the same source pattern in generic deploy.
  4. Support for custom build dependencies resolution per build. 

2.1.2 (12 Dec 2011)

  1. Compatible with Gradle 1.0-milestone-6.

2.1.1 (09 Aug 2011)

  1. Support for Gradle milestone-4
  2. Better support for releasing nested Maven projects
  3. Fixed minor Maven deployments discrepancies

2.1.0 (14 Jul 2011)

  1. Release management capabilities
  2. Bug fixes

2.0.1 (9 Jan 2011)

  1. Auto Snapshot/Release target repository selection
  2. Add ivy/artifact deploy patterns
  3. Improved Gradle support
  4. Bug fixes

2.0.0 (5 Dec 2010)

  1. Support for Gradle builds
  2. Support for maven3 builds
  3. Default deployer add resolver credentials
  4. Support for muti steps builds

1.1.3 (21 Nov 2010)

  1. Include/exclude pattern for artifacts deployment

1.1.2 (7 Nov 2010)

  1. Control for including published artifacts when running license checks
  2. Limiting license checks to scopes
  3. Control for turning off license discovery when running license checks
  • No labels