如何使用Pipeline插件创建含第三方JAR依赖的Jenkins Gradle构建任务？

Alright, let's figure out how to set up your Jenkins job for this Gradle build scenario—where you can't modify the third-party-controlled build.gradle but need to switch between different versions of their JARs. Here are practical, constraint-friendly solutions:

方案1: 用Gradle命令行参数覆盖依赖版本 #

Most third-party build scripts use variables for dependency versions (even if you can't see them directly). Gradle lets you override these variables via -P command-line parameters, which is perfect for your case.

For example, if the third-party build.gradle has something like this:

dependencies {
    implementation "com.thirdparty:core-lib:${thirdPartyCoreVersion}"
    implementation "com.thirdparty:utils:${thirdPartyUtilsVersion}"
}

You can pass the version directly in your Jenkins Gradle build step:

./gradlew build -PthirdPartyCoreVersion=2.4.1 -PthirdPartyUtilsVersion=1.8.0

If the build.gradle uses hardcoded versions (not ideal, but common), you can use Gradle's dependency substitution trick. Add a pre-build shell step in Jenkins to generate a temporary settings.gradle file that overrides the versions:

cat > settings.gradle << EOF
dependencySubstitution {
    substitute module('com.thirdparty:core-lib:1.0.0') with module('com.thirdparty:core-lib:${THIRD_PARTY_VERSION}')
    substitute module('com.thirdparty:utils:1.0.0') with module('com.thirdparty:utils:${THIRD_PARTY_VERSION}')
}
EOF

Then run your Gradle build as usual—it'll pick up the substitution rules without modifying the original build.gradle.

方案2: Jenkins参数化构建 + 本地依赖仓库 #

If the third-party JARs aren't hosted on public repos (like Maven Central), use Jenkins parameterized builds to let you select versions on-demand, then fetch the correct JARs into a local repo before building.

Here's how to set it up:

1. In your Jenkins job, go to General > This project is parameterized and add a String Parameter named THIRD_PARTY_JAR_VERSION (set a default like 1.0.0).
2. Add a pre-build shell step to download the target version JAR into a local Maven-style repo:

# Create local repo structure matching Maven conventions
mkdir -p ./local-repo/com/thirdparty/core-lib/${THIRD_PARTY_JAR_VERSION}
# Download the JAR (replace the URL with your internal repo path)
curl -o ./local-repo/com/thirdparty/core-lib/${THIRD_PARTY_JAR_VERSION}/core-lib-${THIRD_PARTY_JAR_VERSION}.jar http://your-internal-repo/thirdparty/core-lib/${THIRD_PARTY_JAR_VERSION}.jar

3. In your Gradle build step, add the local repo as a repository source:

./gradlew build --repo ./local-repo

This tells Gradle to look in your local repo first for the third-party JARs, using the version you selected in Jenkins.

方案3: Jenkins Pipeline for flexible version switching #

If you're using Jenkins Pipeline (highly recommended for CI/CD flexibility), you can wrap all this logic into a reusable script that supports version selection with a few clicks.

Here's a sample pipeline script:

pipeline {
    agent any
    parameters {
        string(
            name: 'THIRD_PARTY_VERSION',
            defaultValue: '2.4.1',
            description: 'Select the version of third-party JARs to use'
        )
    }
    stages {
        stage('Checkout Source') {
            steps {
                git url: 'https://your-source-repo-url.git', branch: 'main'
            }
        }
        stage('Fetch Third-Party JARs') {
            steps {
                sh """
                    mkdir -p ./local-repo/com/thirdparty/core-lib/${params.THIRD_PARTY_VERSION}
                    curl -o ./local-repo/com/thirdparty/core-lib/${params.THIRD_PARTY_VERSION}/core-lib-${params.THIRD_PARTY_VERSION}.jar \
                        http://your-internal-repo/thirdparty/core-lib/${params.THIRD_PARTY_VERSION}.jar
                """
            }
        }
        stage('Gradle Build') {
            steps {
                // If using parameter override:
                sh "./gradlew build -PthirdPartyVersion=${params.THIRD_PARTY_VERSION} --repo ./local-repo"
                // If using substitution (for hardcoded versions):
                // sh "cat > settings.gradle << EOF
                // dependencySubstitution {
                //     substitute module('com.thirdparty:core-lib:1.0.0') with module('com.thirdparty:core-lib:${params.THIRD_PARTY_VERSION}')
                // }
                // EOF && ./gradlew build --repo ./local-repo"
            }
        }
    }
}

With this pipeline, every time you run the job, you can input or select the desired third-party version, and the pipeline handles fetching and building automatically.

Quick Tips #

• If the third-party provides a BOM (Bill of Materials), use -PplatformVersion=X.Y.Z to override the BOM version instead of individual JAR versions—this keeps versions consistent.
• For frequent version switches, consider adding a Choice Parameter in Jenkins instead of a string parameter, so you can pick from a predefined list of valid versions (avoids typos).

内容的提问来源于stack exchange，提问作者Gaz