Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-47614

Artifactory Plugin fails in Pipeline after upgrade of plugin

      We upgraded the artifactory plugin from 2.12.2 to 2.13.0 and our Pipeline builds can't run anymore.

      Here's the relevant portion of our Jenkinsfile script:

      def artifactory = Artifactory.server('com.redacted')
      def mavenBuild = Artifactory.newMavenBuild()
      mavenBuild.resolver = null
      mavenBuild.deployer server: artifactory, releaseRepo: 'redacted-local', snapshotRepo: 'redacted-snapshots-local'
      mavenBuild.tool = 'Maven 3.3.9'
      env.setProperty('PATH+JDK', javaHome + "bin")
      def coreBuildInfo = mavenBuild.run pom: 'pom.xml', goals: "clean install -s build
      settings.xml -Dmaven.repo.local=.repository -Dmaven.test.failure.ignore=true -B -U -Dbuild.id=$env.BUILD_NUMBER".toString()

      It seems like an exception is being thrown, although a stack trace print didn't put anything into the build log.

      I rolled it back to 2.12.2 and the problem went away.

          [JENKINS-47614] Artifactory Plugin fails in Pipeline after upgrade of plugin

          tyrelh, thank you for reporting this issue.
          We tried to reproduce this but we are missing some details.
          On which step was the failure? could you provide us with console output to the relevant section?
          Why are you setting mavenBuild.resolver = null? this line should not be permitted and will fail.

           

          Roman Gurevitch added a comment - tyrelh , thank you for reporting this issue. We tried to reproduce this but we are missing some details. On which step was the failure? could you provide us with console output to the relevant section? Why are you setting mavenBuild.resolver = null ? this line should not be permitted and will fail.  

          Tyrel Haveman added a comment -

          Unfortunately this is a production system so I can't spend a whole of time playing with debugging on it to try to find out exactly which line the problem is happening on.

          This is the only console output from that stage before it goes to the exception handler:

          [Pipeline] stage
          [Pipeline] { (Core build)
          [Pipeline] getArtifactoryServer
          [Pipeline] newMavenBuild
          [Pipeline] ArtifactoryMavenBuild
          Jenkins Artifactory Plugin version: 2.13.0

          The mavenBuild.resolver = null is there to work around a bug in the Artifactory Plugin. It was added to the Jenkinsfile on Sept 27, 2016, so I don't remember for sure exactly what the deal was with it. I had looked at the plugin's source code and determined that setting it to null would resolve the problem we were experiencing. My git commit message on that line just says "Try a null resolver". Prior to that we weren't using the Artifactory plugin to run the build in this way.

          I could try removing the null resolver, re-upgrading the plugin, and running one build to see if that makes any difference.

          Tyrel Haveman added a comment - Unfortunately this is a production system so I can't spend a whole of time playing with debugging on it to try to find out exactly which line the problem is happening on. This is the only console output from that stage before it goes to the exception handler: [Pipeline] stage [Pipeline] { (Core build) [Pipeline] getArtifactoryServer [Pipeline] newMavenBuild [Pipeline] ArtifactoryMavenBuild Jenkins Artifactory Plugin version: 2.13.0 The mavenBuild.resolver = null is there to work around a bug in the Artifactory Plugin. It was added to the Jenkinsfile on Sept 27, 2016, so I don't remember for sure exactly what the deal was with it. I had looked at the plugin's source code and determined that setting it to null would resolve the problem we were experiencing. My git commit message on that line just says "Try a null resolver". Prior to that we weren't using the Artifactory plugin to run the build in this way. I could try removing the null resolver, re-upgrading the plugin, and running one build to see if that makes any difference.

          Tyrel Haveman added a comment - - edited

          Just a quick update: I haven't been able to get a good time to allow the plugin to be updated, yet, but I have removed the null resolver and the builds still seem to run fine with that; so whatever bug that was about last year, has been fixed.

          Tyrel Haveman added a comment - - edited Just a quick update: I haven't been able to get a good time to allow the plugin to be updated, yet, but I have removed the null resolver and the builds still seem to run fine with that; so whatever bug that was about last year, has been fixed.

          Tyrel Haveman added a comment - - edited

          Okay, I was able to squeeze in some better exception handling, so I now have a stack trace for you:

          java.nio.file.InvalidPathException: Illegal char <*> at index 82: D:\jenkins\jenkins-09\tools\hudson.tasks.Maven_MavenInstallation\Maven_3.3.9\boot*
          at sun.nio.fs.WindowsPathParser.normalize(Unknown Source)
          at sun.nio.fs.WindowsPathParser.parse(Unknown Source)
          at sun.nio.fs.WindowsPathParser.parse(Unknown Source)
          at sun.nio.fs.WindowsPath.parse(Unknown Source)
          at sun.nio.fs.WindowsFileSystem.getPath(Unknown Source)
          at java.nio.file.Paths.get(Unknown Source)
          at org.jfrog.hudson.maven3.Maven3Builder.buildMavenCmdLine(Maven3Builder.java:147)
          at org.jfrog.hudson.maven3.Maven3Builder.perform(Maven3Builder.java:113)
          at org.jfrog.hudson.pipeline.steps.ArtifactoryMavenBuild$Execution.run(ArtifactoryMavenBuild.java:105)
          at org.jfrog.hudson.pipeline.steps.ArtifactoryMavenBuild$Execution.run(ArtifactoryMavenBuild.java:61)
          at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47)
          at hudson.security.ACL.impersonate(ACL.java:260)
          at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44)
          at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
          at java.util.concurrent.FutureTask.run(Unknown Source)
          at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
          at java.lang.Thread.run(Unknown Source)

           
          I think this is probably a Windows-specific problem. My guess is you shouldn't be using Paths in this way to create a file path that's not a real path (wildcard):

          Path classPath = Paths.get(mavenHome.getRemote(), "boot", "*");

          I will roll back again to the previous version of Artifactory plugin until you can come up with an alternative implementation of this.

           

          Tyrel Haveman added a comment - - edited Okay, I was able to squeeze in some better exception handling, so I now have a stack trace for you: java.nio.file.InvalidPathException: Illegal char <*> at index 82: D:\jenkins\jenkins-09\tools\hudson.tasks.Maven_MavenInstallation\Maven_3.3.9\boot* at sun.nio.fs.WindowsPathParser.normalize(Unknown Source) at sun.nio.fs.WindowsPathParser.parse(Unknown Source) at sun.nio.fs.WindowsPathParser.parse(Unknown Source) at sun.nio.fs.WindowsPath.parse(Unknown Source) at sun.nio.fs.WindowsFileSystem.getPath(Unknown Source) at java.nio.file.Paths.get(Unknown Source) at org.jfrog.hudson.maven3.Maven3Builder.buildMavenCmdLine(Maven3Builder.java:147) at org.jfrog.hudson.maven3.Maven3Builder.perform(Maven3Builder.java:113) at org.jfrog.hudson.pipeline.steps.ArtifactoryMavenBuild$Execution.run(ArtifactoryMavenBuild.java:105) at org.jfrog.hudson.pipeline.steps.ArtifactoryMavenBuild$Execution.run(ArtifactoryMavenBuild.java:61) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47) at hudson.security.ACL.impersonate(ACL.java:260) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)   I think this is probably a Windows-specific problem. My guess is you shouldn't be using Paths  in this way to create a file path that's not a real path (wildcard): Path classPath = Paths.get(mavenHome.getRemote(), "boot", "*"); I will roll back again to the previous version of Artifactory plugin until you can come up with an alternative implementation of this.  

          tyrelh,
          We already identified this issue and working on a fix, we will create a fix version soon.

          Roman Gurevitch added a comment - tyrelh , We already identified this issue and working on a fix, we will create a fix version soon.

          tyrelh, we have released Jenkins Artifactory plugin version 2.13.1 that fixes this issue.
          It will be available shortly.
          A Jira ticket for this issue can be found here.

           

          Roman Gurevitch added a comment - tyrelh , we have released Jenkins Artifactory plugin version 2.13.1 that fixes this issue. It will be available shortly. A Jira ticket for this issue can be found here .  

            eyalbe Eyal Ben Moshe
            tyrelh Tyrel Haveman
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: