Jenkins Artifactory插件能否支持Docker-in-Docker？与Kubernetes插件联用问题咨询

Hey there, let's break down your questions and fix the pipeline failure you're facing:

1. Docker-in-Docker (DinD) Support #

First off, the Jenkins Artifactory plugin itself doesn't directly handle DinD setup—it depends on the Jenkins Kubernetes plugin to configure the DinD environment. As long as your Kubernetes pod template includes a DinD sidecar container (with proper privileges, Docker socket volume mounts, etc.), the Artifactory plugin will work seamlessly with it. The plugin interacts directly with build tools like Maven inside your specified containers, so DinD support is totally possible if your Kubernetes setup is configured correctly.

2. Analyzing the HAP-982 Issue #

You’re spot-on to suspect HAP-982—this was a well-known bug where the Artifactory plugin incorrectly searched for tool paths (like MAVEN_HOME) on the Kubernetes Pod’s host node instead of inside the designated maven container.

Looking at your pipeline code, a couple of issues are likely triggering or worsening this problem:

• Tool Configuration Mismatch: When you set rtMaven.tool = 'maven', the plugin tries to reference a Jenkins global tool named "maven". But in your pre-built maven container, Maven is already installed, and the plugin might not map this global tool to the container’s local Maven path.
• BuildInfo Initialization Order: You’re passing buildInfo to rtMaven.run before initializing it with Artifactory.newBuildInfo(), which can lead to unexpected behavior.

3. Fixed Pipeline Example #

Here’s an adjusted version of your pipeline that addresses these issues and resolves the HAP-982 problem:

def label = "worker-${UUID.randomUUID().toString()}"
podTemplate(label: label, containers: [ 
    containerTemplate(name: 'maven', image: 'maven:3.3.9-jdk-8-alpine', ttyEnabled: true, command: 'cat'), 
    containerTemplate(name: 'git', image: 'alpine/git', command: 'cat', ttyEnabled: true) 
]) { 
    node(label) { 
        container('maven') { 
            def server 
            def buildInfo 
            def rtMaven 
            
            stage ('Clone') {
                // Use the dedicated git container for cloning (best practice for separation of concerns)
                container('git') {
                    git url: 'https://github.com/jfrogdev/project-examples.git'
                }
            }
            
            stage ('Test a Maven project') { 
                server = Artifactory.server 'private-artifactory' 
                buildInfo = Artifactory.newBuildInfo() // Initialize buildInfo first
                rtMaven = Artifactory.newMavenBuild() 
                
                // Skip setting `rtMaven.tool` since Maven is pre-installed in the container
                // If you need to enforce a specific tool path, uncomment these lines:
                // rtMaven.tool = 'maven'
                // rtMaven.toolPath = '/usr/share/maven' // Default path in the maven:alpine image
                
                rtMaven.run pom: 'maven-example/pom.xml', goals: 'clean install', buildInfo: buildInfo 
                buildInfo.publish(server) // Ensure build metadata gets sent to Artifactory
            } 
        } 
    }
}

Key improvements:

• Moved the git clone step to the dedicated git container for cleaner separation of concerns
• Initialized buildInfo before passing it to rtMaven.run to avoid null reference issues
• Removed the rtMaven.tool setting (since the container has Maven pre-installed) — add toolPath if you need to explicitly point to the container’s Maven location
• Added buildInfo.publish(server) to make sure build metadata is sent to your Artifactory instance

4. Is HAP-982 Still Present? #

The HAP-982 bug was fixed in Artifactory Jenkins plugin version 3.10.0 and later. To ensure you’re not hitting this issue:

• Upgrade your Artifactory plugin to the latest stable version
• Keep your Jenkins Kubernetes plugin up-to-date to avoid compatibility gaps

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