Jfrog Plugin For Jenkins

Jfrog Plugin For Jenkins is an open source plugin that allows you to connect your Jfrog Community to your Jenkins server.

Jfrog Plugin for Jenkins makes it easy to install and manage JFrog applications. This is especially useful for managing your JFrog application in a public cloud such as IBM Bluemix or Google App Engine.

Jenkins is probably the most popular tool for continuous integration and deployment. It’s great at automating the build and test cycle and providing a lot of feedback in the form of tests. However, there are still a lot of things you can do with Jenkins that aren’t really easy to do. Now one of those things is using Jfrog plugins for Jenkins – giving you the option to run a number of different types of builds without having to change your CI configuration files too much.

Jfrog Plugin For Jenkins


Skip to end of metadata

  • Created by Elana Bakst Salomon, last modified by Or Geva on Sep 28, 2022

Go to start of metadata

Overview

The popular Jenkins Artifactory Plugin brings Artifactory’s Build Integration support to Jenkins.

This integration allows your build jobs to deploy artifacts and resolve dependencies to and from Artifactory, and then have them linked to the build job that created them. The plugin includes a vast collection of features, including a rich pipeline API library and release management for Maven and Gradle builds with Staging and Promotion.

The plugin currently require version 2.159 or above of Jenkins.

The Jenkins Artifactory Plugin supports the following Jenkins Build Jobs:

Pipeline
Freestyle
Maven
Gradle
Ivy-Ant
Generic
Maven
Ivy-Ant

Get started with configuring the Jenkins Artifactory Plug-in.

Learn More

Jenkins Cheat Sheet for Jenkins Pipelines and Continuous Integration

Integration with JFrog Pipelines

General

JFrog Pipelines integration with Jenkins is supported since version 1.6 of JFrog Pipelines and version 3.7.0 of the Jenkins Artifactory Plugin. This integration allows triggering a Jenkins job from JFrog Pipelines. The Jenkins job is triggered using JFrog Pipeline’s native Jenkins step. When the Jenkins job finishes, it reports the status to back to JFrog Pipelines.

The integration supports:

  1. Passing build parameters to the Jenkins job.
  2. Sending data from Jenkins back to JFrog Pipelines.

Setting Up the Integration

  • Open the JFrog Pipelines UI.
  • Under Integrations, click on the Add an Integration button.
  • Choose Jenkins Server integration type and fill out all of the required fields.
  • Click on the Generate button to generate a token. This token is used by Jenkins to authenticate with JFrog Pipelines.
  • Copy the Callback URL and Token, and save them in Jenkins | Manage | Configure System | JFrog Pipelines server

Triggering a Jenkins Job from JFrog Pipelines

To trigger a Jenkins job from JFrog Pipelines, add the Jenkins step In your pipelines yaml as shown here.

- Name: MyJenkinsStep    Type: Jenkins    configuration:        jenkinsJobName: <jenkins-job-name>        Integrations:        - name: MyJenkinsIntegration

Once the Jenkins job finishes, it will report back the status to the Jenkins step.

More Options

For pipelines jobs in Jenkins, you also have the option of sending info from Jenkins back to JFrog Pipelines. This info will be received by JFrog Pipelines as output resources of the Jenkins step in JFrog Pipelines. Here’s how you add those resources to the Jenkins pipeline script:

jfPipelines (    outputResources: """[        {            "name""pipelinesBuildInfo",            "content": {                "buildName""${env.JOB_NAME}",                "buildNumber""${env.BUILD_NUMBER}"            }        }    ]""")

By default, the Jenkins job status and the optional output resources are sent by Jenkins to JFrog Pipelines when the job finishes. You also however have the option of sending the status and output resources before the Jenkins job ends. Here’s how you do it:

jfPipelines (    reportStatus: "SUCCESS")

After Jenkins reports the status back to JFrog Pipelines, it does not wait for any response from JFrog Pipelines, and the job continues to the next step immediately.

You also have the option of putting the reportStatus and outputResources together as follows:

jfPipelines (    reportStatus: "SUCCESS",    outputResources: """[        {            "name""pipelinesBuildInfo",            "content": {                "buildName""${env.JOB_NAME}",                "buildNumber""${env.BUILD_NUMBER}"            }        }    ]""")

The supported statuses are SUCCESS, UNSTABLE, FAILURE, NOT_BUILT or ABORTED.

The Jenkins job will report the status to JFrog Pipelines only once. If you don’t report the status as part fo the pipelines script as shown above, Jenkins will report it when the job finishes.

Multi-Configuration (Freestyle) Projects

A  multi-configuration project can be used to avoid duplicating many similar steps that would otherwise be made by different builds.

The plugin is used in the same way as the other Freestyle builds, but under “Deploy artifacts to Artifactory” you will find a mandatory *Combination Matches *field where you can enter the specific matrix combinations to which the plugin will deploy the artifacts.

Page Contents

Overview
Integration with JFrog Pipelines
Multi-Configuration (Freestyle) Projects
Triggering Builds
JIRA Integration
Build Isolation
Excluded artifacts and the BuildInfo
Discarding Old Builds
Configuring repositories with variables
Dynamically Disabling Deployment of Artifacts and Build-info
Using the Jenkins Job DSL Plugin
Watch the Screencast
Release Notes

Read more

Configuring Jenkins Artifactory Plug-in
Working With Pipeline Jobs in Jenkins
Maven Builds
Gradle Builds
Ivy-Ant Builds
Generic Builds
Jenkins Artifactory Plugin – Release Management
Setting Up Docker Build-info

Integration Benefits

JFrog Artifactory and Jenkins CI

Combination Matches field

Here you can specify build combinations that you want to deploy through a Groovy expression that returns true or false.
When you specify a Groovy expression here, only the build combinations that result in true will be deployed to Artifactory. In evaluating the expression, multi-configuration axes are exposed as variables (with their values set to the current combination evaluated).
The Groovy expression uses the same syntax used in Combination Filter under Configuration Matrix 
For example, if you are building on different agents for different jdk`s you would specify the following:

Deploy “if both linux and jdk7, it’s invalid “!(label==”linux” && jdk==”jdk7″
Deploy “if on master, just do jdk7 “(label==”master”).implies(jdk==”jdk7″)

Important Note

Deployment of the same Maven artifacts by more than one matrix job is not supported!


Triggering Builds

The Artifactory Trigger allows a Jenkins job to be automatically triggered when files are added or modified in a specific Artifactory path. The trigger periodically polls Artifactory to check if the job should be triggered.

To enable the Artifactory trigger, follow these steps:
1. In the Jenkins job UI, go to Build Triggers, and check the Enable Artifactory trigger checkbox.
2. Select an Artifactory server.
3. Define a cron expression in the Schedule field. For example, to pull Artifactory every ten minutes, set */10 * * * *
4. Set a Path to watch. For example, when setting generic-libs-local/builds/starship, Jenkins polls the /builds/starship folder under the generic-libs-local repository in Artifactory for new or modified files.

JIRA Integration

JIRA Integration is supported only in Free-Style and Maven jobs.

Pipeline jobs support a more generic integration, which allows integrating with any issue tracking system. See the Collecting Build Issues section in Declarative and Scripted Pipeline APIs documentation pages.

The Jenkins plugin may be used in conjunction with the Jenkins JIRA plugin to record the build’s affected issues, and include those issues in the Build Info descriptor inside Artifactory and as searchable properties on deployed artifacts.

The SCM commit messages must include the JIRA issue ID. For example:HAP-007 – Shaken, not stirred

To activate the JIRA integration, make sure that Jenkins is set with a valid JIRA site configuration and select the Enable JIRA Integration in the job configuration page:

Aggregating Issues from Previous Builds

It is possible to collect under a build deployed to Artifactory all JIRA issues affected by this build as well as previous builds. This allows you, for example, to see all issues between the previous release to the current build, and if the build is a new release build – to see all issues addresses in the new release.
To accumulate JIRA issues across builds, check the “Aggregate issues from previous builds” option and configure the last build status the aggregation should begin from. The default last status is “Released” (case insensitive), which means aggregation will begin from the first build after the last “Released” one.


Build Isolation

Build Isolation is currently supported only in Free-Style and Maven jobs.

When executing the same chain of integration (snapshot) builds in parallel, a situation may arise in which downstream builds resolve snapshot dependencies which are not the original dependencies existing when the build was triggered.
This can happen when a root upstream build has run and triggered downstream builds that depend on its produced artifacts. Then the upstream has run again before the running downstream builds has finished, so these builds may resolve newly created upstream artifacts that are not meant for them, leading to conflicts.

Solution

The Jenkins plugin offers a new checkbox for its Maven/Gradle builds ‘Enable isolated resolution for downstream builds’ which plants a new ‘build.root’ property that is added to the resolution URL.
This property will then be read by the direct children of this build and implanting them in their resolution URLs respectively, thus guaranteeing that the parent artifact resolved is the one that was built prior to the build being run.

Maven

In order for Maven to use the above feature, the checkbox needs to be checked for the root build only, and make sure that all artifacts are being resolved from Artifactory by using the ‘Resolve artifacts from Artifactory’ feature. This will enforce Maven to use the resolution URL with Maven builds, alongside with the ‘build.root’ property as a matrix param in the resolution URL.

Gradle

Once the ‘Enable isolated resolution for downstream builds’ has been checked, the build.root property will be added to all existing resolvers.


Excluded artifacts and the BuildInfo

By default when providing exclude patterns for artifacts, they will not get deployed into Artifactory but they will get included in the final BuildInfo JSON.
By marking the “Filter excluded artifacts from build Info” the excluded artifacts will appear in a different section inside the BuildInfo and by this providing a clear understanding of the entire Build.
This is also crucial for the promotion procedure, since it scans your BuildInfo JSON and trying to promote all the artifacts there, it will fail when you excluded artifacts unless you mark this option.


Discarding Old Builds

To use this functionality in pipeline jobs, please refer to one of the Triggering Build Retention sections in the Artifactory Pipeline APIs documentation page.

The Jenkins project configuration lets you specify a policy for handling old builds.

You can delete old builds based on age or number as follows:

Days to keep buildsThe number of days that a build should be kept before it is deleted
Max # of builds to keepThe maximum number of builds that should be kept. When a new build is created, the oldest one will be deleted

Once these parameters are defined, in the Post-build Actions section, you can specify that Artifactory should also discard old builds according to these settings as follows:

Discard old builds from ArtifactoryConfigures Artifactory to discard old builds according to the Jenkins project settings above
Discard build artifactsConfigures Artifactory to also discard the artifacts within the build

Configuring repositories with variables

This section is relevant for Free-Style and Maven jobs only,.

You can select text mode in which you can type out your target repository.
In your target repository name, you can use variables that will be dynamically replaced with a value at build time.
The variables should be specified with a dollar-sign prefix and be enclosed by curly brackets.
For example: ${deployRepository}, ${resolveSnapshotRepository}, ${repoPrefix}-${repoName} etc.
The variables are replaced by values from one of the following job environments:

  1. Predefined Jenkins environment variables.
  2. Jenkins properties (Read more in  Jenkins Wiki)
  3. Parameters configured in the Jenkins configuration under the “This build is parameterized” section – these parameters could be replaced by a value from the UI or using the Jenkins REST API.
  4. Injected variables via one of the Jenkins plugins (“EnvInject” for example).

Dynamically Disabling Deployment of Artifacts and Build-info

Maven, Gradle and Ivy builds can be configured to deploy artifacts and/or build information to Artifactory. For example, in the case of Gradle builds, you would set the Publishing repository field and check Capture and publish build-info. Maven and Ivy have similar (although slightly different) configuration parameters. By setting these parameters, you can configure each build tool respectively to deploy build artifacts and/or build information to Artifactory. However, there may be specific cases in which you want to override this setting and disable deploying artifacts and build information. In these cases, you can pass the following two system properties to any of the build tools:

  • artifactory.publish.artifacts
  • artifactory.publish.buildInfo
    For example, for a Maven build, you can add these system properties to the Goals and options field as follows:
clean install -Dartifactory.publish.artifacts=false -Dartifactory.publish.buildInfo=false

To control these properties dynamically, you can replace the values with Jenkins variables or Environment variables that you define as follows

clean install -Dartifactory.publish.artifacts=$PUBLISH_ARTIFACTS -Dartifactory.publish.buildInfo=$PUBLISH_BUILDINFO

Using the Jenkins Job DSL Plugin

The Jenkins Job DSL plugin allows the programmatic creation of jobs using a DSL. Using the Jenkins Job DSL plugin, you can create Jenkins jobs to run Artifactory operations. To learn about the Jenkins Job DSL, see the Job DSL Tutorial.

To view Seed job examples and instructions for each type of Jenkins jobs, see jenkins-job-dsl-examples.

Leave a Comment