Artifactory provides tight integration with TeamCity CI Server through the TeamCity Artifactory Plug-in. Beyond managing efficient deployment of your artifacts to Artifactory, the plug-in lets you capture information about artifacts deployed, dependencies resolved, environment data associated with the TeamCity build runs and more, that effectively provides full traceability for your builds.
From version 2.1.0 the TeamCity Artifactory Plug-in provides powerful features for release management and promotion. For details please refer to TeamCity Artifactory Plugin - Release Management.
Build Runner Support
The TeamCity Artifactory plugin supports most build runner types, including: Maven2, Maven 3, Ivy/Ant (with Ivy modules support), Gradle , NAnt, MSBuild, FxCop and Ipr.
Installing the Plugin
Some features of the plugin are not supported on older versions of Artifactory and TeamCity.
To make full use of the TeamCity Artifactory plugin, the recommended requirements are:
The compatibility matrix below specifies which version of the TeamCity Artifactory Plug-in you should install based on your versions of TeamCity and Artifactory
Plugins are deployed to TeamCity by placing the packaged plugin into the
To use the TeamCity Artifactory plugin you first need to configure your Artifactory servers 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 Artifactory servers configured.
Configuring System-wide Artifactory Servers
To make Artifactory servers globally available to project runner configurations, they must be defined in Administration | Integrations | Artifactory.
Select 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, but they can also be overridden and set at a project build level.
Specifying a username and password for the resolver repository is optional. It is only used when querying Artifactory's REST API for a list of configured repositories and then only 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 | Projects and select the project you want to configure.
Then, under the Build Configurations section, click the Edit link for the build you want to configure.
Under Build Configuration Settings, select the relevant Build Step and click the Edit link for the build step you want to configure.
When you select a value in the Artifactory server URL field, the selected server is queried for a list of configured repositories (using the credentials configured in the corresponding Artifactory Server Configuration). This populates the Target Repository field with a list of repositories to which you can select to deploy.
Clicking on the Free-text mode checkbox enables you to type in repository name as free text. You may also include variables as part of the text.
The Gradle Runner
To help you get started integrating your Gradle builds with Artifactory using the Gradle runner, we recommend using the gradle2-example-ci-server sample Gradle project.
Running License Checks
If you are using Artifactory Pro, you can benefit from the License Control feature to discover and handle third party dependency licensing issues as part of the build.
Black Duck Code Center Integration
If you are using Artifactory Pro and have an account with Black Duck Code Center, you can run the build through an automated, non-invasive, open source component approval process, and monitor for security vulnerabilities.
The project-specific runner configuration offers some advanced options for the following runner types:
Attaching Searchable Parameters to Build-Info and to Published Artifacts
In the Build Configuration Settings you can select Parameters to define system properties or environment variables that should be attached to artifacts and their corresponding build info.
To define a parameter click on the Add new parameter button.
FIll in the corresponding fields.
Parameters relevant for builds run through Artifactory are:
You can specify all the properties in a single file, and then define another property pointing to it.
To point the plugin to a properties file, define a property called
It is also possible to point the plugin to a properties file containing the aforementioned properties.
Viewing Project-specific Configuration
Existing project configuration can be viewed in Settings under Projects | $PROJECT_NAME | $BUILD_NAME:
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 does the following:
You can also link directly to the build 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 in the polled element, the TeamCity build is triggered. For example, the build could be triggered when new artifacts have been deployed to the specified path in Artifactory.
To configure a new build trigger, under Administration, select $PROJECT_NAME | $BUILD_NAME. Then, under Build Configuration Settings select Triggers.
Click the Add new trigger button to select an Artifactory Build Trigger
Select the Artifactory Server URL and the Target repository.
Complete the username and a password fields of a valid deployer for the selected repository.
Then, in Items to watch, specify the paths in the selected repository in which a change should automatically trigger a build.
If the Artifactory server is accessed via a proxy, you need to configure the proxy by setting the following properties in the
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.
Click to see change log details...
2.1.12 (12 Mar 2015)
2.0.0 (5 Dec 2010)
1.1.3 (21 Nov 2010)
1.1.2 (7 Nov 2010)