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

Post-build action "Archive the artifacts" prints exception to console when no artifacts found (regression in 2.108)

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Fixed
    • core
    • Jenkins version 2.121.1
    • 2.344

    Description

      In my job configuration, I have Do not fail build if archiving returns nothing checked under Post-build Actions > Archive the artifacts so that build still completes even if no artifacts are created (this is intentional). The help icon describes this field as such:

      Normally, a build fails if archiving returns zero artifacts. This option allows the archiving process to return nothing without failing the build. Instead, the build will simply throw a warning.

      In Jenkins 2.107.3 this causes the following warning to be printed to the build console:

      15:30:26 Archiving artifacts
      15:30:27 WARN: No artifacts found that match the file pattern "**/data/behat-failure/**/*". Configuration error?
      15:30:28 WARN: java.lang.InterruptedException: no matches found within 10000
      

      However, in Jenkins 2.121.1 the following big ugly stack trace is now printed to the build console:

      12:28:36 Archiving artifacts
      12:28:36 java.lang.InterruptedException: no matches found within 10000
      12:28:36 	at hudson.FilePath$34.hasMatch(FilePath.java:2678)
      12:28:36 	at hudson.FilePath$34.invoke(FilePath.java:2557)
      12:28:36 	at hudson.FilePath$34.invoke(FilePath.java:2547)
      12:28:36 	at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2918)
      12:28:36 Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to [redacted]
      12:28:36 		at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741)
      12:28:36 		at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
      12:28:36 		at hudson.remoting.Channel.call(Channel.java:955)
      12:28:36 		at hudson.FilePath.act(FilePath.java:1036)
      12:28:36 		at hudson.FilePath.act(FilePath.java:1025)
      12:28:36 		at hudson.FilePath.validateAntFileMask(FilePath.java:2547)
      12:28:36 		at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:243)
      12:28:36 		at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:81)
      12:28:36 		at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
      12:28:36 		at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744)
      12:28:36 		at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:690)
      12:28:36 		at hudson.model.Build$BuildExecution.post2(Build.java:186)
      12:28:36 		at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:635)
      12:28:36 		at hudson.model.Run.execute(Run.java:1819)
      12:28:36 		at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
      12:28:36 		at hudson.model.ResourceController.execute(ResourceController.java:97)
      12:28:36 		at hudson.model.Executor.run(Executor.java:429)
      12:28:36 Caused: hudson.FilePath$TunneledInterruptedException
      12:28:36 	at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2920)
      12:28:36 	at hudson.remoting.UserRequest.perform(UserRequest.java:212)
      12:28:36 	at hudson.remoting.UserRequest.perform(UserRequest.java:54)
      12:28:36 	at hudson.remoting.Request$2.run(Request.java:369)
      12:28:36 	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
      12:28:36 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
      12:28:36 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
      12:28:36 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
      12:28:36 	at java.lang.Thread.run(Thread.java:748)
      12:28:36 Caused: java.lang.InterruptedException: java.lang.InterruptedException: no matches found within 10000
      12:28:36 	at hudson.FilePath.act(FilePath.java:1038)
      12:28:36 	at hudson.FilePath.act(FilePath.java:1025)
      12:28:36 	at hudson.FilePath.validateAntFileMask(FilePath.java:2547)
      12:28:36 	at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:243)
      12:28:36 	at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:81)
      12:28:36 	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
      12:28:36 	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744)
      12:28:36 	at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:690)
      12:28:36 	at hudson.model.Build$BuildExecution.post2(Build.java:186)
      12:28:36 	at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:635)
      12:28:36 	at hudson.model.Run.execute(Run.java:1819)
      12:28:36 	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
      12:28:36 	at hudson.model.ResourceController.execute(ResourceController.java:97)
      12:28:36 	at hudson.model.Executor.run(Executor.java:429)
      12:28:36 No artifacts found that match the file pattern "**/data/behat-failure/**/*". Configuration error?
      

      Attachments

        Issue Links

          Activity

            jglick I agree with you about about single quote vs double quotes. I usually use single quotes to the max and this is what I was doing but I need GString interpolation before when I had written it as https://github.com/xwiki/xwiki-jenkins-pipeline/blob/f8c4f536dcbb0524f9348c989003857a540bc70d/vars/xwikiBuild.groovy#L190

            Then I forgot to replace the double quotes by single quotes after I refactored it...

            That said using single quotes shouldn't change anything to the problem. There's no GString interpolation in my string AFAICS (no dollar sign). Thus the problem will remain IMO.

            Or better yet, just move all this stuff into your regular build script so it produces the desired artifacts in a tidy directory ready for Jenkins to publish, which is something you can easily test locally. There is no reason to clutter Jenkinsfile with complex embedded scripts.

            This is what our regular Maven build script does. It generates these results in the `target/` directory (i.e. in a clean location). The issue here is the maven reactor and multimodules. Our build script is fine IMO and gathering of artifacts is not a build responsibility. All we're asking Jenkins is to archive some of the artifacts in `target/` because we're using Docker Cloud and the docker agent container is removed after each run and thus we need to save some of the artifacts in the job results.

            BTW all this is done in our pipeline library and not inside the Jenkinsfile which remains clean and generic.

            Not sure why cleaning a directory would be complex in any setup. rm -rf tmp-jenkins-png && mkdir tmp-jenkins-png does not suffice?

            Yes, I think I was wrong here. We should be able to do this just before we do the checkout in our pipeline library.

            Side note: I thought that the `clearWorkspace` parameter in the `checkout` step (https://jenkins.io/doc/pipeline/steps/workflow-scm-step/) would clean the workspace but apparently it does not (it probably does something else). I tried to find the source code that uses this parameter to see what it does but couldn't track it (I ended up in SCM.java but I see no use of it there either). I checked it by creating a file in the workspace and then calling the pipeline and the file remained.

            Thanks

            vmassol Vincent Massol added a comment - jglick I agree with you about about single quote vs double quotes. I usually use single quotes to the max and this is what I was doing but I need GString interpolation before when I had written it as https://github.com/xwiki/xwiki-jenkins-pipeline/blob/f8c4f536dcbb0524f9348c989003857a540bc70d/vars/xwikiBuild.groovy#L190 Then I forgot to replace the double quotes by single quotes after I refactored it... That said using single quotes shouldn't change anything to the problem. There's no GString interpolation in my string AFAICS (no dollar sign). Thus the problem will remain IMO. Or better yet, just move all this stuff into your regular build script so it produces the desired artifacts in a tidy directory ready for Jenkins to publish, which is something you can easily test locally. There is no reason to clutter Jenkinsfile with complex embedded scripts. This is what our regular Maven build script does. It generates these results in the `target/` directory (i.e. in a clean location). The issue here is the maven reactor and multimodules. Our build script is fine IMO and gathering of artifacts is not a build responsibility. All we're asking Jenkins is to archive some of the artifacts in `target/` because we're using Docker Cloud and the docker agent container is removed after each run and thus we need to save some of the artifacts in the job results. BTW all this is done in our pipeline library and not inside the Jenkinsfile which remains clean and generic. Not sure why cleaning a directory would be complex in any setup. rm -rf tmp-jenkins-png && mkdir tmp-jenkins-png does not suffice? Yes, I think I was wrong here. We should be able to do this just before we do the checkout in our pipeline library. Side note: I thought that the `clearWorkspace` parameter in the `checkout` step ( https://jenkins.io/doc/pipeline/steps/workflow-scm-step/ ) would clean the workspace but apparently it does not (it probably does something else). I tried to find the source code that uses this parameter to see what it does but couldn't track it (I ended up in SCM.java but I see no use of it there either). I checked it by creating a file in the workspace and then calling the pipeline and the file remained. Thanks
            borisivan boris ivan added a comment -

            Is there any progress on this? Allowing empty archive should stifle this massive stack trace. New users looking at the output from their pipeline trip up over this and ask about it all the time, (as they should).

            borisivan boris ivan added a comment - Is there any progress on this? Allowing empty archive should stifle this massive stack trace. New users looking at the output from their pipeline trip up over this and ask about it all the time, (as they should).
            borisivan boris ivan added a comment -

            still a problem, still have users assume that something is broken because of the errors and stacktrace in the log.

            borisivan boris ivan added a comment - still a problem, still have users assume that something is broken because of the errors and stacktrace in the log.

            Feel the same pains as Boris. Have been dealing with this for at least a couple of years now.

            rmestre Ricardo Mestre added a comment - Feel the same pains as Boris. Have been dealing with this for at least a couple of years now.
            basil Basil Crow added a comment -

            Fixed in jenkinsci/jenkins#6475. Released in 2.344.

            basil Basil Crow added a comment - Fixed in jenkinsci/jenkins#6475 . Released in 2.344.

            People

              gregswift Greg Swift
              pholden Paul Holden
              Votes:
              8 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: