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

Unstash with symlinks fails

    XMLWordPrintable

Details

    • 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 danielbeck wfollonier jglick

      Attachments

        Activity

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

          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?

          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]
          
          
          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]

          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

          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
          jglick Jesse Glick added a comment -

          yrsurya 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.

          jglick Jesse Glick added a comment - yrsurya 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.
          danielbeck Daniel Beck added a comment -

          planned for 2.319.1

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

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

          People

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

            Dates

              Created:
              Updated:
              Resolved: