Jenkins Pipeline task cannot find script due to creating @tmp path

I am writing a job on a pipeline that calls another script to execute. Jenkins and script files exist in the same directory, but the script cannot be found in the job.

This is the corresponding bit of the script;

stage ('Update') { try { dir('jenkins/pipeline/update-jenkins-plugins-ppln') { sh 'ls -l' sh 'update-plugins.sh' } } 

which returns the following error:

 [update-jenkins-plugins-ppln] Running shell script + ls -l total 8 -rw-r--r-- 1 jenkins jenkins 2441 Dec 20 09:34 Jenkinsfile -rwxr-xr-x 1 jenkins jenkins 506 Dec 19 14:06 update-plugins.sh [Pipeline] sh [update-jenkins-plugins-ppln] Running shell script + update-plugins.sh /var/lib/jenkins/workspace/update-jenkins-plugins-ppln/jenkins/pipeline/update-jenkins-plugins-ppln@tmp/durable-11cefdd0/script.sh: 2: /var/lib/jenkins/workspace/update-jenkins-plugins-ppln/jenkins/pipeline/update-jenkins-plugins-ppln@tmp/durable-11cefdd0/script.sh: update-plugins.sh: not found 

As you can see, the path I'm using is correct because, according to ls file I need update-plugins.sh is in the directory I update-plugins.sh to. For some reason, although when searching for a Jenkins script, @tmp/durable-8d48734f/script.sh added to the path.

Various troubleshooting methods:

  • I read that you need to check the branch again, even if you are already checking it to get the Jenkins file, so there I am.
  • I have ssh'd in the Jenkins field to check and yes, the script is.

Why is Jenkins adding the @tmp bit, and is there a way to prevent this behavior?

+14
git bash jenkins groovy
source share
5 answers

Have you tried using the jenkins WORKSPACE workspace environment WORKSPACE (absolute workspace path)? In this case, your line will look something like this:

 sh '${WORKSPACE}/jenkins/pipeline/update-jenkins-plugins-ppln/update-plugins.sh' 
+3
source share

I think your pwd is not in PATH, so you should call it like this: sh './update-plugins.sh'

+2
source share

I had the same problem. I think @Oren technically answered your question about why Jenkins creates this tmp space, but I can share some information on how I solved this.

Essentially, my Jenkins host contains bin/sh references to dash ; not bash . Thus, using a POSIX-compatible shell script solved this problem for me.

For example, I tried to use shopt -s extglob for pattern matching:

 stage { def shellCommand = $/ "rm -rf ! (_data|_includes|_plugins|Gemfile|_config.yml|page-builder)"/$ sh(returnStdout: true, script: shellCommand).trim() } 

Since dash does not support extglob , extglob replacement for the POSIX-compatible find :

 stage { sh('find . -regextype posix-extended -not -regex ".*includes.*|.*data.*|.*plugins.*|.*config.yml|.*Gemfile.*"') } 
+1
source share

The @tmp folder is intended for statistics of Jenkins work and stages (duration of stages, etc.), you can delete it if you want to be sure of this. I assume your problem is due to the wrong path, double check it.

0
source share

I assume this particular case has nothing to do with Jenkins pipelines, as it can be played outside of Jenkins in the console. I once got this problem because of the end of the DOS line in my script that I ran in the "sh ()" pipeline. Take a look at this example:

 $ cat -v dos_formatted.sh #! /bin/sh^M pwd^M $ cat script.sh ./dos_formatted.sh $ sh -xe script.sh + ./dos_formatted.sh script.sh: 1: script.sh: ./dos_formatted.sh: not found 

This illustrates well that the message "not found" is misleading. The script is in the right place, and there is enough permission, but when you run it from another script, it crashes with this error message.

The Durable Task plugin code ( https://github.com/jenkinsci/durable-task-plugin/blob/master/src/main/java/org/jenkinsci/plugins/durabletask/BourneShellScript.java ) shows that the plugin launches automatically generated script.sh as "sh -xe ...", so this is definitely our case.

The situation described above may occur if you are a "git clone" in some (possibly third-party) Git project and are not sure if it was cloned with Unix-style LF.

0
source share

All Articles