Artifactory is a universal Artifact Repository Manager by JFrog. IBM UrbanCode Build 6.1.3 can integrate with Artfactory to upload/download artifact files to/from various repositories hosted in Artifactory. Artifactory essentially takes the place of the built-in repository without losing visibility or usability.
In order to be able to work with Artifactory repositories in IBM UrbanCode Build, you would first need to install the Artifactory plugin from the IBM UrbanCode Build plugins website. The latest plugin version available at the time of writing this post is version 11.
After installing the plugin, the following job steps will be available in IBM UrbanCode Build:
- Upload to Repository – Upload artifacts to an Artifactory repository
- Download from Repository – Download artifacts from an Artifactory repository
- Upload Build Information – Add build-related information to an artifact that has already been uploaded to Artifactory
In this blog post, we will walk through these job steps and see how they can be used to work with Artifactory from IBM UrbanCode Build 6.1.3.
The latest UCB cumulative patch for IBM UrbanCode Build 6.1.3 should be used as it contains changes that the plugin needs in order to function properly.
Configuring an Artifactory Integration in IBM UrbanCode Build
Before being able to execute the Artifactory plugin steps in a job configuration, an Artifactory server needs to be configured so that IBM UrbanCode Build knows where the Artifactory server is located. This configuration can be done via System > Integration > Artifactory.
After a server has been configured, the Artifactory plugin steps can reference this server when uploading or downloading files.
Uploading Artifacts to Artifactory
After artifact files have been produced and are ready to be uploaded to a repository, the plugin step Upload to Repository can be used to send the artifact files to a repository hosted in an Artifactory server.
When uploading artifacts to Artifactory, it is important to use a unique Target Path for each build life of IBM UrbanCode Build. Different build lives should not upload artifacts under the same target path in Artifactory as this will cause difficulties when tracing the published artifacts to the particular build life that has produced them.
If Preserve Artifact Directories checkbox is checked, the artifacts will be uploaded to the repository by combining the target path and the local file paths based off the working directory offset. In the example picture shown above, if there is a local artifact with path dev/file.txt under the current working directory, and if the target path is artifacts/1234, then checking the Preserve Artifact Directories will result in uploading this artifact to the final target path of artifacts/1234/dev/file.txt in the specified Artifactory repository. Without checking this checkbox, this artifact would have been uploaded to the final target path of artifacts/1234/file.txt.
Downloading Artifacts from Artifactory
In order to download artifact files from an Artifactory repository, each artifact’s target path should be specified in a separate line in the input text area of the download step. The download path should not include the repository’s name.
If desired, the SHA-1 checksum of the downloaded artifacts can be verified after downloading by checking the checkbox for Verify Hash. By doing so, the plugin will calculate the SHA-1 checksum of the downloaded file, and compares it to checksum of this artifact in the relevant Artifactory repository. If the two values do not match, the step execution will fail.
Uploading Build Information
Artifactory supports adding build-related information to artifacts which can provide valuable information for tracing purposes when using a CI tool such as IBM UrbanCode Build. This plugin step reads the build information from a local JSON file and uploads it to the Artifactory server. Linking the build information to relevant artifact files happens automatically by Artifactory via the SHA-1/MD5 checksum of the artifacts.
A very simple build information JSON data may look like the following:
For more information on the JSON format expected by Artifactory, the Artifactory REST API documentation will be handy.
In order to produce the build information JSON file, a Shell or Groovy plugin step can be used. The following is a very simple Shell step that produces build information for a single artifact file:
After uploading the json data to Artifactory, the build information can be viewed in Artifactory’s Build Browser:
Viewing Uploaded Build Life Artifacts
IBM UrbanCode Build provides an internal artifact repository called CodeStation, which can be used to store build life artifacts after they are produced as part of each build. Alternatively, artifacts may also be uploaded to an external artifact repository such as Artifactory. The Artifacts tab of the build life page in IBM UrbanCode Build can show the list of artifacts that have been uploaded to Artifactory during the build life’s execution.
When retrieving artifact file data to display in the Artifacts tab, IBM UrbanCode Build will first try to use the deep listing API of Artifactory which is available in Artifactory Pro. However, when using Artifactory OSS, this API is not available. In this case, IBM UrbanCode Build will fall back to the regular listing API which does not provide checksum or file size information. In addition, the non-deep listing information only includes files and directories that are directly under the target path.
Therefore, if for example, the artifact file dev/file1.txt is uploaded to Artifactory with target path artifacts/664 and Preserve Artifact Directories checkbox is checked, then the Artifacts tab will only display dev as the published artifact. Further information can be retrieved by clicking the artifact file’s name which will redirect to Artifactory.
When using Artifactory Pro, on the other hand, the deep listing API enables IBM UrbanCode Build to retrieve complete file information even when preserving artifact file directories: