We Created a New Plugin
General
We have recently released a new next-gen plugin - the Jenkins JFrog Plugin. The new plugin can be installed and used side by side with the Jenkins Artifactory plugin. If you're already using the Artifactory Plugin, we recommend also installing the new JFrog Plugin, and gradually migrating your jobs from the old plugin to the new one. You can also have your existing jobs use the two plugins. The old plugin will continue to be supported, however new functionality will most likely make it into the new plugin only.
Why Did We Create the New Plugin?
We want to ensure that the Jenkins plugin continues receiving new functionality and improvements. that are added very frequently to JFrog CLI. JFrog CLI already includes significantly more features than the Jenkins Artifactory Plugin. The new JFrog plugin will be receiving these updates automatically.
How Is the New Plugin Different from the Old One?
Unlike the old plugin, the new plugin completely relies on JFrog CLI, and serves as a wrapper for it. This means that the APIs you'll be using in your Pipeline jobs look very similar to JFrog CLI commands. The new plugin also does not support UI based Jenkins jobs, such as Free-Style jobs. It supports Pipeline jobs only.
How Do I Get Started?
Read the JFrog Plugin documentation to get started.
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:
Get started with configuring the Jenkins Artifactory Plug-in.
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:
Passing build parameters to the Jenkins job.
Sending data from Jenkins back to JFrog Pipelines.
Setting Up the Integration
Open the JFrog Pipelines UI.
Under Integrations, click on theAdd an Integrationbutton.
Choose Jenkins Serverintegration type and fill out all of the required fields.
Click on the Generatebutton 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: MyJenkinsIntegrationOnce 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.
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
Note
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
Note
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
Note
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 builds | The number of days that a build should be kept before it is deleted |
Max # of builds to keep | The 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 Artifactory | Configures Artifactory to discard old builds according to the Jenkins project settings above |
Discard build artifacts | Configures 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:
Predefined Jenkins environment variables.
Jenkins properties (Read more in Jenkins Wiki)
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.
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.
Watch the Screencast
To see the Jenkins Artifactory Integration in action you can watch the following screencast.