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

Unstash with symlinks fails

    XMLWordPrintable

    Details

    • Similar Issues:
    • Released As:
      2.320,2.319.1

      Description

      See https://github.com/jenkinsci/jenkins/runs/4107177325
      https://github.com/jenkinsci/jenkins/pull/5881/checks?check_run_id=4107861004

      Logs:
      https://ci.jenkins.io/job/Core/job/jenkins/job/PR-5881/2/execution/node/116/

      java.nio.file.NoSuchFileException: /home/jenkins/workspace/Core_jenkins_PR-5881/ath/athSources/src/main/resources/ath-container/run.sh
      	at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
      	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
      	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
      	at java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219)
      	at java.base/java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:484)
      	at java.base/java.nio.file.Files.newOutputStream(Files.java:228)
      	at hudson.util.IOUtils.copy(IOUtils.java:52)
      	at hudson.FilePath.readFromTar(FilePath.java:2862)
      Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to EC2 (aws-us-east-2) - High memory ubuntu 20.04 (i-02b6bda105ac6c6d9)
      		at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1797)
      		at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:356)
      		at hudson.remoting.Channel.call(Channel.java:1001)
      		at hudson.FilePath.act(FilePath.java:1166)
      		at hudson.FilePath.act(FilePath.java:1155)
      		at hudson.FilePath.untar(FilePath.java:617)
      		at org.jenkinsci.plugins.workflow.flow.StashManager.unstash(StashManager.java:161)
      		at org.jenkinsci.plugins.workflow.support.steps.stash.UnstashStep$Execution.run(UnstashStep.java:77)
      		at org.jenkinsci.plugins.workflow.support.steps.stash.UnstashStep$Execution.run(UnstashStep.java:64)
      		at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
      		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:829)
      Caused: java.io.IOException: Failed to extract athSources.tar.gz
      	at hudson.FilePath.readFromTar(FilePath.java:2872)
      	at hudson.FilePath.access$500(FilePath.java:213)
      	at hudson.FilePath$UntarRemote.invoke(FilePath.java:633)
      	at hudson.FilePath$UntarRemote.invoke(FilePath.java:622)
      	at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3338)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:211)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:54)
      	at hudson.remoting.Request$2.run(Request.java:376)
      	at hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
      	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
      	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
      	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
      	at java.base/java.lang.Thread.run(Thread.java:833)
      

      Started just after the controller was upgraded to the security release

      cc Daniel Beck Wadeck Follonier Jesse Glick

        Attachments

          Activity

          Hide
          yrsurya suryatej yaramada added a comment -

          Please let me know if there is any workaround for this issue? or planning to release any new version to patch this?

          Show
          yrsurya suryatej yaramada added a comment - Please let me know if there is any workaround for this issue? or planning to release any new version to patch this?
          Hide
          yrsurya suryatej yaramada added a comment -

          Tried reverting back to 2.303.2 but facing this issues

           [plugins : There are 21 failed plugins: workflow-durable-task-step; workflow-basic-steps; gradle; pipeline-model-definition; pipeline-as-yaml; external-workspace-manager; blueocean-pipeline-api-impl; blueocean-bitbucket-pipeline; workflow-aggregator; tekton-client; blueocean-github-pipeline; throttle-concurrents; blueocean-pipeline-editor; github-autostatus; docker-workflow; blueocean-events; templating-engine; artifactory; blueocean-git-pipeline; dark-theme; blueocean]
          
          
          Show
          yrsurya suryatej yaramada added a comment - Tried reverting back to 2.303.2 but facing this issues [plugins : There are 21 failed plugins: workflow-durable-task-step; workflow-basic-steps; gradle; pipeline-model-definition; pipeline-as-yaml; external-workspace-manager; blueocean-pipeline-api-impl; blueocean-bitbucket-pipeline; workflow-aggregator; tekton-client; blueocean-github-pipeline; throttle-concurrents; blueocean-pipeline-editor; github-autostatus; docker-workflow; blueocean-events; templating-engine; artifactory; blueocean-git-pipeline; dark-theme; blueocean]
          Hide
          yrsurya suryatej yaramada added a comment -

          After reinstalling Nodes and Processes Plugin looks like our deployments functionality restored where we are on 2.303.2 version .. But it would be nice if we can have a fix release for this

          Show
          yrsurya suryatej yaramada added a comment - After reinstalling Nodes and Processes Plugin looks like our deployments functionality restored where we are on 2.303.2 version .. But it would be nice if we can have a fix release for this
          Hide
          jglick Jesse Glick added a comment -

          suryatej yaramada as in issue metadata, this is fixed in 2.320, and planned for 2.319.1. We were not currently planning a 2.303.4 just for this issue.

          The workaround should be simple: do not attempt to stash symlinks. If you have a directory tree including symlinks which you need to save & restore in that form, you can always run for example tar from a shell before stash’ing the tarball, and untar after unstash; specific options to tar will give you full control over how the symlinks are interpreted in your build workspace.

          Show
          jglick Jesse Glick added a comment - suryatej yaramada as in issue metadata, this is fixed in 2.320, and planned for 2.319.1. We were not currently planning a 2.303.4 just for this issue. The workaround should be simple: do not attempt to stash symlinks. If you have a directory tree including symlinks which you need to save & restore in that form, you can always run for example tar from a shell before stash ’ing the tarball, and untar after unstash ; specific options to tar will give you full control over how the symlinks are interpreted in your build workspace.
          Hide
          danielbeck Daniel Beck added a comment -

          planned for 2.319.1

          Expected release date is Dec 1, so just another week too

          Show
          danielbeck Daniel Beck added a comment - planned for 2.319.1 Expected release date is Dec 1, so just another week too

            People

            Assignee:
            danielbeck Daniel Beck
            Reporter:
            timja Tim Jacomb
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: