Using Artifactory 5.x ?
JFrog Artifactory 5.x User Guide
Have a question? Want to report an issue? Contact JFrog support
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.
Before you begin
Please refer to the general information about Artifactory's Build Integration before using the TeamCity Artifactory Plugin.
Source Code Available!
The TeamCity Artifactory Plugin is an open source project on GitHub which you can freely browse and fork.
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
Plugins are deployed to TeamCity by placing the packaged plugin into the
$TEAMCITY_USER_HOME/plugins folder and restarting TeamCity. You can also accomplish this via the TeamCity UI via Administration | Plugins List | Upload Plugin Zip and choosing the zip-file from your file-system. You will need to restart TeamCity (tomcat) for the plugin to take effect.
Download version 2.3.1 (the latest release) of the plugin from here.
Remove older versions
If you have an older version of the plug-in, be sure to remove it before upgrading to a newer one
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.
For example: libs-%variableName%
If the Target Repository list remains empty, check that 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.
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.
If you check the Run License Checks checkbox, Artifactory will scan and check the licenses of all dependencies used by this build. You can also specify a list of recipients who should receive any license violation notifications by email.
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.
Generic Build Integration
Generic build integration provides Build Info support for the following runner types:
- Command Line
- XCode Project
- NuGet Publish
- Visual Studio (sln)
- Visual Studio 2003
- SBT, Scala build tool
This allows the above builds to:
- Upload any artifacts to Artifactory, together with custom properties metadata, and keep published artifacts associated with the TeamCity build.
- Download artifacts from Artifactory that are required by your build.
You can define the artifacts to upload and download by either using "File Specs" or "Legacy Patterns".
File Spec are specified in JSON format. You can read the File Spec schema here.
Legacy Patterns (deprecated)
Legacy patterns are deprecated since version 1.8.0 and will be removed in future releases.
Custom published artifacts
|Allows you to specify which artifact files produced by the build should be 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 applyinga 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.|
Custom build dependencies
|Allows 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.
If no matching artifacts are found, remember that these parameters may be case sensitive depending on the operating system, the agent and the server they are running on.
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:
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
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
buildInfoConfig.propertiesFile and set its value to the absolute path of the properties file.
It is also possible to point the plugin to a properties file containing the aforementioned properties.
The properties file should be located on the machine running the build agent, not on the server!
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:
- For all build runner types - Publishes the specified Published Artifacts to the selected target repository and applies corresponding path mappings.
- For Maven or Ivy/Ant build runner - Deploys all artifacts to the selected target repository together at the end of the build (as opposed to deploying separately at the end of each module build as done by Maven and Ivy).
- 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 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.
Artifactory Pro required
Triggering builds is only available with Artifactory Pro
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.
The specified user must have deploy permissions on the repository
Then, in Items to watch, specify the paths in the selected repository in which a change should automatically trigger a build.
Be as specific as possible in Items to watch
In order to establish if there has been a change, Artifactory must traverse all the folders and their sub-folders specified in Items to watch. If the specified folders have a lot of content and sub-folders, this is a resource intensive operation that can take a long time.
Therefore, we recommend being as specific as possible when specifying folders in Items to watch.
If the Artifactory server is accessed via a proxy, you need to configure the proxy by setting the following properties in the
$TEAMCITY_USER_HOME/.BuildServer/config/internal.properties file. If the file does not exist, you'll need to create it.
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.
- Support full path in specs (TCAP-287)
- Add to file spec the ability to download artifact by build name and number (TCAP-288)
- Change file Specs pattern (TCAP-285)
- Upload and download File Specs support to generic jobs (TCAP-284)
- Bug fix (TCAP-214)
- Bug fixes (TCAP-238, TCAP-239, TCAP-241, TCAP-244, TCAP-245, TCAP-247, TCAP-250, TCAP-258, TCAP-236)
- Support multi Artifactory Build Triggers (TCAP-222)
- Support SBT build tool (TCAP-223)
- Bug fix (TCAP-214)
2.1.12 (12 Mar 2015)
- Adding support for free text repository configuration (TCAP-217)
- Adding Version Control Url property to the Artifactory Build Info JSON. (TCAP-203)
- Support for TeamCity 8.1 Release management feature issues
- Support working with maven 3.1.1
- Bug Fixed (TCAP-197, TCAP-161)
- Add support for blackduck integration - TCAP-185
- TeamCity 8.0.x full compatability issue - TCAP-172
- Global and build credentials issue - TCAP-153
- Repositories refreshed by credential issue - TCAP-166
- Generic deploymentresolution on Xcode builds - TCAP-180
- Working directory in Gradle build issue - TCAP-125
- Compatible with TeamCity7.1.
- Bug Fixes
- Compatible with TeamCity7.
- Support 'Perforce' in release management.
- Support multiple deploy targets for the same source pattern in generic deploy.
- Support for custom build dependencies resolution per build.
- Compatible with Gradle 1.0-milestone-6.
- Support for Gradle milestone-4
- Better support for releasing nested Maven projects
- Fixed minor Maven deployments discrepancies
- Release management capabilities
- Bug fixes
- Auto Snapshot/Release target repository selection
- Add ivy/artifact deploy patterns
- Improved Gradle support
- Bug fixes
2.0.0 (5 Dec 2010)
- Support for Gradle builds
- Support for maven3 builds
- Default deployer add resolver credentials
- Support for muti steps builds
1.1.3 (21 Nov 2010)
- Include/exclude pattern for artifacts deployment
1.1.2 (7 Nov 2010)
- Control for including published artifacts when running license checks
- Limiting license checks to scopes
- Control for turning off license discovery when running license checks