-
Type:
Task
-
Status: Open (View Workflow)
-
Priority:
Major
-
Resolution: Unresolved
-
Component/s: workflow-basic-steps-plugin
-
Labels:
-
Environment:Jenkins 2.121.2 on a CentOS 7
-
Similar Issues:
In order to install some internal tools within /opt/tools through a Jenkins job, I have created a /opt/tools directory belonging to jenkins:jenkins and where user jenkins only (the user running the slave) has rwx rights.
Trying something like :
stages {
steps('xyz') {
dir('/opt/tools') {
sh "pwd"
}
}
}
Fails with an exception ending with :
java.nio.file.AccessDeniedException: /opt/tools@tmp at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) at sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384) at java.nio.file.Files.createDirectory(Files.java:674) at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781) at java.nio.file.Files.createDirectories(Files.java:767) at hudson.FilePath.mkdirs(FilePath.java:3098) at hudson.FilePath.access$900(FilePath.java:209) at hudson.FilePath$Mkdirs.invoke(FilePath.java:1216) at hudson.FilePath$Mkdirs.invoke(FilePath.java:1212) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2913) at hudson.remoting.UserRequest.perform(UserRequest.java:212) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:369) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)
It appears that Jenkins tries to create a tools@tmp directory at the same level as tools. Yet, there is absolutely no reason for the tools root directory to be writable for any user.
And as far as /opt is concerned here, for sure it must not be writable for anybody else than root.
Additionnally, such @tmp directory is not removed once the build is achieved. Even though it seems that the directory is empty, I think that Jenkins should remove it to give back a clean environment.
Adjacent sh steps should be coalesced, and if possible their content externalized to a versioned script so that you are left with only a short one-line sh argument. Of course on occasion there is a reason for there to be intervening steps of other types.
Jesse Glick ‘Simply’ adding a sh “cd /opt/tools” does not work in a declarative pipeline. Subsequent sh steps will have their current directory reset back to the workspace directory. This is frustrating and not documented.
A have a pipeline which builds and creates installer/.zip archive. I'm using "dir" to change directory to a folder and execute python script there. The problem I encountered is that now the installer/zip contains additional empty folder@tmp.
Edit: I've read the explanation that Devin wrote again, and I see that it's not "dir" that created the folder@tmp, but rather the "sh" step (or in my case - the "bat" step probably).
Is that the only step that does it?
It's a bit problematic. Now I'm affraid to use "dir", because who knows how will it affect other steps? And it's a very useful step...
If "sh"/"bat" is the only such step, maybe it could create the temp folder in some location for temporary files, if jenkins provides such thing. If not, maybe jenkins could be extended to provide it.
Do not use dir for this purpose. Simply start your sh script with cd /opt/tools.
Hi all,
The point is not only related to sh something, it is a more generic issue. Have I done the same with python, ruby or groovy step, I would have the same.
The point is actually that when a dir() occurs, a @tmp folder is created behind the scene, and this is potentially a problem in some cases.