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 arichpipeline API libraryandrelease management for Maven and Gradle buildswith Staging and Promotion.
The Jenkins Artifactory Plugin supports the following Jenkins Build Jobs:
Amulti-configuration projectcan be used to avoid duplicating many similar steps that would otherwise be made by different builds.
使用的插件一样另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.
Here you can specify build combinations that you want todeploythrough a Groovy expression that returns true or false. When you specify a Groovy expression here, only the build combinations that result intruewill 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 inCombination FilterunderConfiguration 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
TheArtifactory Triggerallows 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 toBuild Triggers, and check theEnable Artifactory triggercheckbox. 2. Select anArtifactory server. 3. Define a cron expression in theSchedulefield. For example, to pull Artifactory every ten minutes, set*/10 * * * * 4. Set aPath to watch. For example, when settinggeneric-libs-local/builds/starship, Jenkins polls the/builds/starshipfolder under thegeneric-libs-localrepository 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 theCollecting Build Issuessection inDeclarativeandScriptedPipeline APIs documentation pages.
The Jenkins plugin may be used in conjunction with theJenkins JIRA pluginto 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:哈P-007 - Shaken, not stirred
To activate the JIRA integration, make sure that Jenkins is set with a valid JIRA site configuration and select theEnable JIRA Integrationin 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 thedirectchildren 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.
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 thePost-build Actionssection, 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:
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 thePublishing repositoryfield and checkCapture 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 theGoals and optionsfield as follows:
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 theJob DSL Turotial.
To view Seed job examples and instructions for each type of Jenkins jobs, seejenkins-job-dsl-examples.
Watch the Screencast
To see the Jenkins Artifactory Integration in action you can watch the following screencast.
Artifactory plugin is back to support Maven 2 (哈P-459)
New feature, "Refresh Repositories" button, a convenient way to see your available repositories that exists in the configured Artifatory. This feature also improves the Job page load response, and fixes the following bug (哈P-483)
Supporting "Subversion plugin" version 2.+, on their compatibility with "Credentials plugin" (哈P-486)
Generic artifact resolution (based on patterns or other builds output) to freestyle builds (哈P-292)
Optimized deploy - when a binary with the same checksum as an uploaded artifact already exists in the Artifactory storage, a new local reference will be created instead of reuploading the same content
从远程奴隶——工件dep Maven部署loyment for Maven builds will run directly from a remote slave when artifact archiving is turned off, saving valuable bandwidth and time normally consumed by copying artifacts back to master for archiving and publishing (requires Maven 3.0.2 and above)
Staging of Maven builds now correctly fails if snapshot dependencies are used in POM files (哈P-183)
All staging and promotion commit comments are now customizable (哈P-181)
Fix for staged builds failing on remote slaves (哈P-189)
