Updating to Artifactory plugin v3.5.0 from v3.4.1 breaks the Artifactory Gradle resolver / deployer steps, seems like it thinks the repo name is empty (https://github.com/jenkinsci/artifactory-plugin/blob/master/src/main/java/org/jfrog/hudson/pipeline/common/types/deployers/GradleDeployer.java#L49)
Here is the pipeline stage which fails:
stage('Initialize Gradle') { steps { rtGradleResolver( id: 'artifactory-gradle-resolver', serverId: 'VonLatvala Artifactory', repo: 'gradle-remote', ) rtGradleDeployer( id: 'artifactory-gradle-deployer', serverId: 'VonLatvala Artifactory', repo: 'cloudsaber-client', ) rtGradleRun( usesPlugin: true, tool: GRADLE_TOOL, useWrapper: false, buildFile: 'build_ci.gradle', tasks: 'init', resolverId: 'artifactory-gradle-resolver', ) } }
And here is the errormessage + stacktrace:
java.io.IOException: The Deployer should be set with either 'repo' or both 'releaseRepo' and 'snapshotRepo' at org.jfrog.hudson.pipeline.common.types.deployers.GradleDeployer.validateRepositories(GradleDeployer.java:57) at org.jfrog.hudson.pipeline.common.types.deployers.GradleDeployer.getDetails(GradleDeployer.java:32) at org.jfrog.hudson.pipeline.common.types.deployers.GradleDeployer.getContextBuilder(GradleDeployer.java:162) at org.jfrog.hudson.pipeline.common.executors.EnvExtractor.createPublisherContext(EnvExtractor.java:54) at org.jfrog.hudson.pipeline.common.executors.EnvExtractor.createArtifactoryClientConfiguration(EnvExtractor.java:75) at org.jfrog.hudson.pipeline.common.executors.EnvExtractor.execute(EnvExtractor.java:64) Caused: java.lang.RuntimeException at org.jfrog.hudson.pipeline.common.executors.EnvExtractor.execute(EnvExtractor.java:69) at org.jfrog.hudson.pipeline.common.executors.GradleExecutor.execute(GradleExecutor.java:66) at org.jfrog.hudson.pipeline.declarative.steps.gradle.GradleStep$Execution.run(GradleStep.java:135) at org.jfrog.hudson.pipeline.declarative.steps.gradle.GradleStep$Execution.run(GradleStep.java:109) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47) at hudson.security.ACL.impersonate(ACL.java:290) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834)
As stated in the title, seems like HAP-1174 introduced this bug.
Build #10 with plugin version v3.4.1
Build #11 with plugin version v3.5.0
Build #12 with plugin version v3.4.1