Build Integration

Skip to end of metadata
Go to start of metadata
Table of Contents

Introduction

Assimilating Artifactory into a continuous integration build process is really straight forward - you simply treat The CI server as a regular build client and, as such, the CI server will resolve dependencies from Artifactory and deploy artifacts into a dedicated repository inside Artifactory.

The Build Integration feature of Artifactory takes this integration one big step forward, by making Artifactory and your CI server closely integrated to provide fully-reproducible builds and full visibility of deployed artifacts, used dependencies and information about build environment.

By using the Build Integration add-on you will:

  • Be able to see all the builds that published their build results to Artifactory.
  • Explore each build's modules, including published artifacts and dependencies with their scope.
  • Get the information about the original build environment.
  • Check if a specific artifact is required/a result of a build, including alerting if such an artifact should be targeted for removal.
  • Manipulate all the artifacts and/or dependencies from a specific build as a single unit (move, copy, export etc.).
  • Get bidirectional links between build and artifact information inside the build server and Artifactory pages.

Jenkins/Hudson, Team City and Bamboo Integrations

The Build Integration currently supports Jenkins/Hudson, TeamCity and Bamboo. Similar integration with other build technologies stacks, are currently being worked-on - stay tuned.

The build technologies supported are: Maven 3 and 2, Gradle, Ivy/Ant, .Net and Generic builds (look under each CI server to see the technologies supported by the plugin for this server).

To learn more about installation and usage instructions specific to your CI server, please follow these links:

The Jenkins/Hudson Artifactory Plug-in The TeamCity Artifactory Plug-in The Bamboo Artifactory Plug-in


The difference between the open source and the commercial version of Build Integration
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.
Module Artifacts and Dependencies View, Repository View of Builds and the ability to export and manipulate build items require the Artifactory Power Pack.

Inspecting and Managing Builds

Builds and Per-Build History

After you have run a build in your your CI server that deployed to Artifactory, you can immediately see the corresponding build results inside Artifactory. A new 'Builds' menu item lists all known CI server projects that published their build results:

Each build corresponds to its CI server project (job) counterpart and contains a build history of all runs, that reflect the build history in the CI server:

For each build item in the history you can drill down into and get more fine details about it, as explained in the next section. You can also view the build in the CI server by selecting 'Show in CI Server'.
You can of course also navigate back to Artifactory from the CI server UI.

To view build information users need to have a 'deployer' permission on some repository path (at minimum).

Build-level Information

Drilling-down into the single build level, each build contains tree parts of information:

  1. Visual general build information about the build and its environment.
  2. Visual views for modules with their artifacts and dependencies.
  3. Generic view of the build information in JSON format.

General Build Information

This section contains general information about the build.

It is also from here, that you can save the build's artifacts and/or dependencies as a Smart Search Result, for further manipulation, as we will see later.

Build Modules

Each build publishes module(s) into Artifactory, which are seen on this view, together with the number of artifacts and dependencies which they contain:

Module Artifacts and Dependencies

If we drill even further down, we will be able to inspect each module's published artifacts and dependencies. Note that deployed artifacts are collected with their types, and dependencies contain the scope(s) that the dependencies were used in during the build. You can also go from each item to its tree view in Artifactory and view other details about it.

Build Environment

In the Environment tab, you can view build properties and other environmental details that are otherwise lost if we want to replay the build in a later point in time (e.g. JDK used, system architecture etc.).

Licenses

In the Licenses tab, you receive a centralized view of all the artifacts and dependencies that were involved and their license analysis.

See the License Control documentation to learn more about this cool feature.

Release History

The Release History tabs displays a timeline of the selected build's release landmarks.

Generic BuildInfo View

The generic BuildInfo view displays an JSON representation of the data that is used to form the visual build information in Artifactory. This can be used by REST or for debugging and is also exposed in the basic OSS version of Artifactory. See towards the end of this chapter for more information about the BuildInfo object.

Exporting and Manipulating Build Items

From the build's general information panel, you can save the build's artifacts and/or dependencies as a Smart Search Result and then manipulate it in order to promote it to another repository, copy it or export all the items to disk to have an external distributable unit of the build with all its dependencies and artifacts.

Repository View of Builds

Artifacts inside Artifactory are also aware of their possible association to builds. When an artifact is associated with a build, either as a published artifact or as a dependency it is visible on a new Builds tab (when selecting the artifact in the tree view).
Moreover, you will also receive warnings when trying to remove from the UI, an artifact that is associated with one or more builds and which without, build reproducibility will be affected.
You can navigate directly from the Builds view to the build information in Artifactory or to the build page in your CI Server:

Artifacts association with builds is kept no matter if you move or copy the artifact inside Artifactory, since this association is maintained by the artifact's checksum which remains constant, regardless of the artifact's location.

Behind the Scenes

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

  1. It deploys all the artifacts in one go to Artifactory. This is done in an optimized fast way and only at the end of the build, which guarantees a more coherent deployment when building multi-module projects (Maven and Ivy's way deploys at the end of each sub-module cycle, which can result in partial deployments if the build fails in a late module).
  2. It sends a BuildInfo data object to Artifactory via REST at the end of deployment. BuildInfo is a structured JSON object that contains all the data about the build environment, artifacts and dependencies, in a standard and open way.
    You can find latest BuildInfo Java-bindings artifacts here and the source here.
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
    1. Feb 23, 2010

      Fixed. Thanks!

  1. Mar 31, 2010

    hi!

    I was wondering if there is a way to trigger a reload of the buildinfo object as a "hudson post-build task" ?

    the idea here is that i wish to perform a maven release with hudson :

    - checkout sources

    - replace "VERSION-snapshot" with my release version (typically with a sed script)

    - launch my build

    Problem is that hudson reads the pom file prior to executing the "pre build tasks". This leads the buildinfo to take those same information (which still contain SNAPSHOT) even though my poms no longer contain SNAPSHOT.

    Therefore when i upload the build using the artifactory plugin, my build is linked (in artifactory) to SNAPSHOT instead of my actual released jars.

    i agree that this scenario is a bit far fetched, but i don't want to use the release plugin of maven to keep a better hand on all the release steps.

    1. Mar 31, 2010

      It will be possible to handle this type of scenario soon via Artifactory's REST promotion mechanism - stay tuned .

  2. Oct 06, 2011

    When jenkins deploy a build to the artifactory, the artifactory don't create files pom.xml on libs-snapshot-local for each jar deployed.

    Someone can tell me why this happens?