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

Wrong working dir used on Windows if executed command is in a subfolder

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Not A Defect
    • Component/s: xshell-plugin
    • Labels:
      None
    • Environment:
      Any Windows platform
    • Similar Issues:

      Description

      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:
      https://github.com/whimboo/mozmill-ci/blob/master/jenkins-master/jobs/functional-test/config.xml#L78

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

        Attachments

          Activity

          Hide
          whimboo Henrik Skupin added a comment -

          As it has been turned out it was really an issue on our side. Sorry for the false alarm.

          Show
          whimboo Henrik Skupin added a comment - As it has been turned out it was really an issue on our side. Sorry for the false alarm.

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            whimboo Henrik Skupin
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: