Gradle Builds with Artifactory - Declarative Pipeline Syntax

Gradle builds can resolve dependencies, deploy artifacts and publish build-info to Artifactory.

To run Gradle builds with Artifactory from your Pipeline script, you first need to create an Artifactory server instance, as described in the Creating an Artifactory Server Instance section.

The next step is to define an rtGradleResolver closure, which defines the dependencies resolution details, and an rtGradleDeployer closure, which defines the artifacts deployment details. Here's an example:

rtGradleResolver (
    id: 'resolver-unique-id',
    serverId: 'Artifactory-1',
    repo: 'maven-remote'
)
     
rtGradleDeployer (
    id: 'deployer-unique-id',
    serverId: 'Artifactory-1',
    repo: 'libs-snapshot-local',
    // Optional - By default, 3 threads are used to upload the artifacts to Artifactory. You can override this default by setting:
    threads: 6,
    // Optional - Attach custom properties to the published artifacts:
    properties: ['key1=value1', 'key2=value2'],
        // Optional - Gradle allows customizing the list of deployed artifacts by defining publications as part fo the Gradle build script. 
        // Gradle publications are used to group artifacts together. You have the option of defining which of the defined publications Jenkins should use. Only the artifacts grouped by these publications will be deployed to Artifactory.
        // If you do not define the publications, a default publication, which includes the list of the produced artifacts by a java project will be used. 
        // Here's how you define the list of publications.
        publications: ["mavenJava", "ivyJava"]
    // If you'd like to deploy the artifacts from all the publications defined in the gradle script, you can set the "ALL_PUBLICATIONS" string as follows
    // publications: ["ALL_PUBLICATIONS"]
)

As you can see in the example above, the resolver and deployer should have a unique ID, so that they can be referenced later in the script, In addition, they include an Artifactory server ID and the names of release and snapshot maven repositories.

If you're using gradle to build a project, which produces maven artifacts, you also have the option of defining two deployment repositories as part the rtGradleDeployer closure - one repository will be used for snapshot artifacts and one for release artifacts. Here's how you define it:

rtGradleDeployer (
    id: 'deployer-unique-id',
    serverId: 'Artifactory-1',
        releaseRepo: 'libs-release',
        snapshotRepo: 'libs-snapshot'
)   

Now we can run the Gradle build, referencing the resolver and deployer we defined:

rtGradleRun (
        // Set to true if the Artifactory Plugin is already defined in build script.
    usesPlugin: true,
        // Tool name from Jenkins configuration. 
    tool: GRADLE_TOOL,
        // Set to true if you'd like the build to use the Gradle Wrapper.
        useWrapper: true,
    rootDir: 'gradle-examples/gradle-example/',
    buildFile: 'build.gradle',
    tasks: 'clean artifactoryPublish',
    resolverId: 'resolver-unique-id',
    deployerId: 'deployer-unique-id',
    // If the build name and build number are not set here, the current job name and number will be used:
    buildName: 'my-build-name',
    buildNumber: '17',
    // Optional - Only if this build is associated with a project in Artifactory, set the project key as follows.
    project: 'my-project-key'
)

In case you'd like Gradle to use a different JDK than your build agent's default, no problem.

Simply set the JAVA_HOME environment variable to the desired JDK path (the path to the directory above the bin directory, which includes the java executable).

Here's you do it:

environment {
    JAVA_HOME = '/full/path/to/JDK'
}

The last thing you might want to do, is to publish the build-info for this build. See the Publishing Build Info to Artifactory section for how to do it.