If a build step with XShell calls a command which is not in the current working dir but in a sub folder, the sub folder is used as current working dir. This issue only persists on Windows and cannot be seen on Linux or Mac.
Just take a command (which is a wrapper script) like:
scripts/run hg clone https://hg.mozilla.org/qa/mozmill-automation
It should clone the given repository into the nodes working dir, but right now it will end up as 'scripts/mozmill-automation'. So the wrapper scripts working dir is used.
Calling the wrapper script from outside Jenkins it works fine, so it has to be a XShell bug.
As reference of a problematic job see:
Steps to reproduce:
1. Clone https://github.com/whimboo/mozmill-ci/
2. Follow the readme and setup the system
3. Add a node for Windows
4. Run 'Build Now' on the functional testrun (Branch: mozilla-central, Platform: win32, Locale: en-US, BuildId: 20120328115525, Nodes: win_xp, Env-Platform: Windows)
5. Check the working dir of the project and notice that the hg clone is not ending up in the root working dir
There is also no difference with executeFromWorkingDir enabled or disabled.
|Field||Original Value||New Value|
|Summary||Wrong workspace used on Windows if executed command is in a subfolder||Wrong working dir used on Windows if executed command is in a subfolder|
|Resolution||Not A Defect [ 7 ]|
|Status||Open [ 1 ]||Resolved [ 5 ]|
|Workflow||JNJira [ 143731 ]||JNJira + In-Review [ 190707 ]|