-
Bug
-
Resolution: Unresolved
-
Major
-
1.509.4
Old description:
pre-scm-buildstep assumes that the directory workspace exists when it's running. However, when setting up a project, it does not exist, and thus this step will fail unless the admin creates manually. Proper behaviour should be to check if it exists, and create it if it doesn't. Otherwise, if it does not exist, the execute shell will fail
The issue also applies to system calls invoked from other places
- is related to
-
-
- Closed
-
[JENKINS-11370] "The directory name is invalid" on Windows slaves
Niklas Saers
created issue -
Here is the full stacktrace from the console when the pre-scm build plugin tries to reference the non-existent workspace. This will happen any time a new job which has no namespace in the slave filesystem uses the pre-scm plugin.
Started by user <username>
Building remotely on <slave node> in workspace /some/path/on/slave
Running Prebuild steps
[<job name>] $ cmd /c call C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\hudson334444854237146312.bat
The directory name is invalid
FATAL: command execution failed
java.io.IOException: Cannot run program "cmd" (in directory "/some/path/on/slave"): CreateProcess error=267, The directory name is invalid
at java.lang.ProcessBuilder.start(Unknown Source)
at hudson.Proc$LocalProc.<init>(Proc.java:244)
at hudson.Proc$LocalProc.<init>(Proc.java:216)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:707)
at hudson.Launcher$ProcStarter.start(Launcher.java:338)
at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:932)
at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:899)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at hudson.remoting.Engine$1$1.run(Engine.java:60)
at java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: CreateProcess error=267, The directory name is invalid
at java.lang.ProcessImpl.create(Native Method)
at java.lang.ProcessImpl.<init>(Unknown Source)
at java.lang.ProcessImpl.start(Unknown Source)
... 17 more
Failed build for hudson.tasks.BatchFile@535c37ae
Updated the issue.
I suppose it is not related to [pre-scm-buildstep], because it also appears in other build steps
| Component/s | New: core [ 15593 ] | |
| Component/s | Original: plugin [ 15491 ] | |
| Description | Original: pre-scm-buildstep assumes that the directory workspace exists when it's running. However, when setting up a project, it does not exist, and thus this step will fail unless the admin creates manually. Proper behaviour should be to check if it exists, and create it if it doesn't. Otherwise, if it does not exist, the execute shell will fail |
New:
Old description: {quote} pre-scm-buildstep assumes that the directory workspace exists when it's running. However, when setting up a project, it does not exist, and thus this step will fail unless the admin creates manually. Proper behaviour should be to check if it exists, and create it if it doesn't. Otherwise, if it does not exist, the execute shell will fail {quote} The issue also applies to system calls invoked from other places |
| Environment | Original: OS X | New: 1.509.4 |
| Labels | New: slave | |
| Priority | Original: Minor [ 4 ] | New: Major [ 3 ] |
| Summary | Original: pre-scm-buildstep assumes workspace exists | New: "The directory name is invalid" on Windows slaves |
| Labels | Original: slave | New: slave windows workspace_corruption |
| Labels | Original: slave windows workspace_corruption | New: slave windows workspace workspace_corruption |
Oleg: I don't see the core issue here. Could you elaborate? Automatic creation of the directory could well hide bugs.
| Assignee | New: Oleg Nenashev [ oleg_nenashev ] |
The issue rarely appears in following plugins:
- Wokspace cleanup plugin
- Perforce plugin
BTW, I'm also not sure about the issue's origin.
It could be caused by JNA libraries, FileSystem / OS specifics, etc., etc.
All plugins use Jenkins core's methods to manage directories, I've supposed that it's better to re-assign the issue to the core
Do you have tested the nvInject plugin?
Maybe it is an alternative to your issue.
Anyway, you could use the EnvInject plugin to setup the job workspace.