Using the latest version?
JFrog Platform User Guide

Skip to end of metadata
Go to start of metadata


Artifactory supports build integration whether you are running builds on one of the common CI servers in use today, on cloud-based CI servers or standalone without a CI server.

Integration of Artifactory into your build ecosystem provides important information that supports fully reproducible builds through visibility of artifacts deployed, dependencies and information on the build environment.

The Artifactory Build Integration Add-on provides a set of plugins you can use with industry standard CI systems and build tools that enable you to:

  • See all the builds that are published and their build results in Artifactory.
  • Explore the modules of each build, including published artifacts and corresponding dependencies.
  • Obtain information about the build environment.
  • Check if a specific artifact is required for or is a result of a build, and providing alerts if such an artifact should be targeted for removal.
  • Treat all the artifacts and/or dependencies from a specific build as a single unit and perform bulk operations such as move, copy, export etc.
  • Receive bidirectional links between build and artifact information inside the build server and Artifactory pages.

Running Builds on a CI Server

Artifactory can easily be added to a continuous integration build ecosystem by treating the CI server as a regular build client, so that it resolves dependencies from Artifactory, and deploys artifacts into a dedicated repository within Artifactory.

Supported Plugins

CI servers that are currently supported, each through a specific plugin are:

The build tools supported on all of these CI servers are: Maven 3 and 2GradleIvy/Ant.Net, MSBuild as well as Generic build tools. For details please refer to the documentation for each CI server plugin.

Bintray Plugins

 In addition to the plugins supported by Artifactory, there is also the Gradle Bintray Plugin which provides integration between Gradle builds directly with JFrog Bintray.

Running Standalone Builds or on a Cloud-based CI Server

In the last few years, the popularity of cloud-based CI servers has grown. Some examples are, CircleCI, Travis and Codeship. The problem is that none of these are "pluggable" in the traditional way. Therefore, to run builds running on cloud-based build servers, as well as standalone builds while using Artifactory to resolve dependencies and upload builds along with exhaustive build information, you can use JFrog CLI which provides extensive build integration capabilities. For details, please refer to Build Integration in the JFrog CLI User Guide.

Build Integration for Artifactory open source version vs. Artifactory Pro

When using the OSS version of Artifactory, Build Integration includes the Generic BuildInfo View and the ability to traverse and view build information using Artifactory's REST APIs.

Artifactory Pro extends these capabilities and provides Module Artifacts and Dependencies View, Repository View of Builds and the ability to export and manipulate build items.

Build Info Repository

Available from Artifactory version 6.6, the Build Info repository, is a local repository that stores your build info json files as artifacts, providing you with:

  • user / group permission management equivalent to managing permissions on repositories with include/exclude patterns on build names 
  • build info replication to other instances, since they are stored as artifacts in a repository 
  • improved accessibility to the build info json files and overall performance of the Builds module

Whenever a new build is uploaded to Artifactory (either by a CI server plugin, directly using a Build REST API or from the Artifactory UI), it will automatically get deployed to this default artifactory-build-info repository.

Build info json files should be uploaded to the root of the repository. Artifactory will automatically place them in the repository using the following structure: artifactory-build-info > [build name] > [build number]-[deploy timestamp].json

Using the artifactory-build-info repository

The artifactory-build-info repository is automatically created and used by default. It cannot be removed. Removing it will cause all your build info to be deleted and a new default build info repository will be recreated.

Cleanup Policies

If you have existing cleanup policies, defined in Artifactory User Plugins, that delete artifacts from your local repositories according to a policy, they will also affect the artifactory-build-info repository and should be updated accordingly. Exclude this repository from your cleanup policies to ensure that your build info files are not deleted.

Migrating to the artifactory-build-info Repository 

The migration process may be configured through the following system properties. The migration will run on the primary node.

Property Name

[Default: 100]

Specifies the number of rows that should be retrieved each time the migration job queries the database for build info json entries that exist in the database but not yet in the build-info repository values.


[Default: 10]

Build info json artifacts are deployed concurrently in batches, then a sleep cycle is initiated. This property specifies the number of artifacts in each batch.

[Default: 2]

Specifies the number of concurrent threads that should execute actual build info artifact updates.

Each concurrent artifact update will incur a read from the database to retrieve the build info json, followed by an upload to the build-info repo.



[Default: 5000 milliseconds]

Specifies the duration of the sleep cycle which is initiated after each batch of updates.

[Default: 300000 milliseconds]

The build-info repository migration can only start when the cluster has been fully upgraded and all nodes run the same minimal required version (6.6.0), where applicable.

This parameter specifies the amount of time the master node will wait between each check for all of the other nodes' current version.

Deleting a Build

To delete a build from the UI, hover over a version and click delete.

Inspecting Builds

Builds and Build History

All CI server projects that deploy their output to Artifactory can be viewed in the Build Browser module.

Selecting a build item to display all runs of that build reflecting the build history in the CI server, and a complete build-level information.


To view build information you must have the 'deploy' permission on some repository path.

Build-level Information

You can select the Build Name to drill down into a specific build. This displays detailed information about the build, and enables you to compare it with another build as described in the following sections.

The build page is broken down into 3 sections: Build ID, General Information 

The Build Info Details screen is divided into three panels:

  • The Build ID panel displays all versions of the selected build. 
  • The horizontal panel along the top displays basic information about the selected version.
  • The Build details. Select a file to see its details in the panel on the right.

There are three categories of information:

  1. General build information about the build and its environment.
  2. Build modules along with their artifacts and dependencies.
  3. Generic view of the build information in JSON format.

General Build Information

The horizontal panel displays general information about the build:

The CI server managing the build
Build Agent
The specific version of build tool used
The time stamp when the build was started
The duration of the build
The factor that triggered this build. This may be a CI server user, or another build
Artifactory Principal
The Artifactory user that triggered this build

Published Modules

This tab displays the modules published into Artifactory as a result of the build, along with the number of artifacts and dependencies that they contain.

Module Artifacts and Dependencies

Selecting a published module that was built will display its artifacts and dependencies. You can group these by type or scope by clicking the corresponding column header. 

You can click any item to download it directly, or click its Repo Path to view it in the Tree Browser.

Module Artifacts and Dependencies


The Environment tab displays an extensive list of properties and environment settings defined for the selected build. You can use these to reproduce the environment precisely if you need to rerun the build.

Build Environment


The Issues provides integration between Artifactory, Jenkins CI server and JIRA issue tracker. When using Jenkins CI, if you to set the  Enable JIRA Integration option in the Jenkins Artifactory Plugin, the Issues tab will display any JIRA issues that have been addressed by this build. 

Build Issues


The Licenses tab displays the results of a detailed license analysis of all artifacts and their dependencies.


The Summary line displays the number of artifacts found with the following statuses:


The license found has not been approved for use

Approving licenses

You can approve a license for use in the Admin tab under Configuration | Licenses. For details please refer to License Control.

Not Found
No license requirements were found for the artifact.
The artifact requires a license that is unknown to Artifactory
A license requirement that is not approved has been found for the artifact, however there is another license that is approved.
All license requirements for the artifact are approved in Artifactory.

Build Diff

The Diff tab allows you to compare the selected build with any other build. Once you select a build number in the Select A Build To Compare Against field, Artifactory displays all the differences between the builds that were detected including new artifacts added, dependencies deleted, properties changed and more.

Build Diff

Release History

The Release History tab displays a list of the selected build's release landmarks.

Build Info JSON

Generic BuildInfo View

This tab displays the raw BuildInfo JSON representation of the build information in Artifactory. This data can be accessed via the REST API or used for debugging and is also available in the Artifactory OSS version.

Build Info JSON

Exporting and Manipulating Build Items

You can view a build in the repository browser and perform actions on it as a whole with all its artifacts and dependencies. For example, you could promote it to another repository, copy it, or export it to a disk.

Exporting and manipulating a build

Repository View of Builds

When viewing an artifact within the Tree Browser, you can see all of the builds with which that artifact is associated, whether directly or as a dependency in the Builds tab

Moreover, if you try to remove the artifact you will receive a warning that the build will no longer be reproducible.

Viewing a build in the repository browser

The association of an artifact with a build is retained even if you move or copy it within Artifactory, because the association linked to the artifact's checksum which remains constant, regardless of the its location.

Behind the Scenes

Behind the scenes, the Artifactory plug-in for your CI server performs two major tasks:

  1. It resolves all dependencies from a resolution repository in Artifactory.
  2. It deploys all the artifacts to Artifactory as an atomic operation at the end of the build, guaranteeing a more coherent deployment when building multi-module projects 
    (Maven and Ivy deploy each module at the end of its build cycle. If one of the modules fails, this can result in partial deployments).
  3. It sends a BuildInfo data object to Artifactory via the REST API at the end of deployment. This is a structured JSON object containing all the data about the build environment, artifacts and dependencies, in a standard and open format.

You can find the latest BuildInfo Java-binding artifacts here and the source here.

Release Management

Artifactory supports release management through its plugins for JenkinsTeamCity and Bamboo.

When you run your builds using Maven or Gradle with jobs that use Subversion, Git or Perforce as your version control system, you can manually stage a release build allowing you to:

  • Change values for the release and next development version

  • Choose a target staging repository to which to deploy the release

  • Create a VCS tag for the release

Staged release builds can later be promoted or rolled-back, changing their release status in Artifactory, with the option to move the build artifacts to a different target repository.

Inside Artifactory, the history of all build status change activities (staged, promoted, rolled-back, etc.) is recorded and displayed for full traceability.

To learn more about release management specific to your CI server, please refer to:

(star) Release Management in the Jenkins Documentation
(star) TeamCity Artifactory Plugin - Release Management
(star) Bamboo Artifactory Plug-in - Release Management

  • No labels