• Pipeline - April 2018

      After updating durable-task from 1.6 to 1.7 workflow builds fail to execute bat steps:

      [Workflow] bat
      [workspace] Running batch script
      'cmd' is not recognized as an internal or external command,
      operable program or batch file.
      

      After switching back to durable-task version 1.6 everything is working again as expected

          [JENKINS-32000] durable-task 1.7 breaks workflow bat steps

          Jesse Glick added a comment -

          Working for me. Switched from call … to cmd /c …. Cannot guess why Windows would claim that cmd does not exist, unless you somehow managed to remove the system entry from your %Path%?

          Jesse Glick added a comment - Working for me. Switched from call … to cmd /c … . Cannot guess why Windows would claim that cmd does not exist, unless you somehow managed to remove the system entry from your %Path% ?

          Jesse Glick added a comment -

          …though even that would not make sense, since the changed code is run only in a script which itself is run via cmd /c.

          Any specific steps to reproduce? Version of Windows?

          Jesse Glick added a comment - …though even that would not make sense, since the changed code is run only in a script which itself is run via cmd /c . Any specific steps to reproduce? Version of Windows?

          Christoph Vogtländer added a comment - - edited

          Unfortunately no specific steps to reproduce. This happens on Windows Server 2012.
          Currently I'm using Pipeline plug-in 1.13 and everything worked fine for a while. As a workaround I added a "withEnv()" wrapper when calling "bat" step adding "c:\\windows;c:\\windows
          system32" to PATH manually.
          Last week I added a new bat step (with the same PATH workaround) to my script and suddenly I get this error message again (EDIT: I simply overlooked one "bat" usage without the workaround).
          Unfortunately the "withEnv()" wrapper does not seem to write anything to the log. So I'm not able to tell whether the environment looked OK or not when "bat" was called.

          Christoph Vogtländer added a comment - - edited Unfortunately no specific steps to reproduce. This happens on Windows Server 2012. Currently I'm using Pipeline plug-in 1.13 and everything worked fine for a while. As a workaround I added a "withEnv()" wrapper when calling "bat" step adding "c:\\windows;c:\\windows system32" to PATH manually. Last week I added a new bat step (with the same PATH workaround) to my script and suddenly I get this error message again ( EDIT : I simply overlooked one "bat" usage without the workaround). Unfortunately the "withEnv()" wrapper does not seem to write anything to the log. So I'm not able to tell whether the environment looked OK or not when "bat" was called.

          the script I use is very simple:

          println("Running build step")
          node('master') {
              println("Generating list of translatable strings")
              bat "if not exist test md test"
          }
          

          which results in:

          Started by user User
          [Pipeline] echo
          Running build step
          [Pipeline] Allocate node : Start
          Running on master in D:\Jenkins\jobs\TestWorkflow\workspace
          [Pipeline] node {
          [Pipeline] echo
          Generating list of translatable strings
          [Pipeline] bat
          [workspace] Running batch script
          'cmd' is not recognized as an internal or external command,
          operable program or batch file.
          [Pipeline] } //node
          [Pipeline] Allocate node : End
          [Pipeline] End of Pipeline
          ERROR: script returned exit code 9009
          Finished: FAILURE
          

          Running this on a node works as expected. So the "master" node seems to be in some strange state.
          Changing the code to

          println("Running build step")
          node('master') {
              println("Generating list of translatable strings")
              def _path = "c:\\windows;c:\\windows\\system32"
              withEnv(["PATH+TOOLS=${_path}", "TMP=d:\\tmp"]) {
                  bat "if not exist test md test"
              }
          }
          

          works around the problem.

          Christoph Vogtländer added a comment - the script I use is very simple: println( "Running build step" ) node( 'master' ) { println( "Generating list of translatable strings" ) bat " if not exist test md test" } which results in: Started by user User [Pipeline] echo Running build step [Pipeline] Allocate node : Start Running on master in D:\Jenkins\jobs\TestWorkflow\workspace [Pipeline] node { [Pipeline] echo Generating list of translatable strings [Pipeline] bat [workspace] Running batch script 'cmd' is not recognized as an internal or external command, operable program or batch file. [Pipeline] } //node [Pipeline] Allocate node : End [Pipeline] End of Pipeline ERROR: script returned exit code 9009 Finished: FAILURE Running this on a node works as expected. So the "master" node seems to be in some strange state. Changing the code to println( "Running build step" ) node( 'master' ) { println( "Generating list of translatable strings" ) def _path = "c:\\windows;c:\\windows\\system32" withEnv([ "PATH+TOOLS=${_path}" , "TMP=d:\\tmp" ]) { bat " if not exist test md test" } } works around the problem.

          In the global Jenkins settings I have set "Prepare jobs environment" -> "Unset System Environment Variables" and I can confirm that this is causing the issue on my master node (why slave nodes are not affected remains unclear to me, the nodes have not specific setting regarding to environment variables).

          IMHO bat-steps should still work even if the "Unset System Environment Variables" option is set.

          Christoph Vogtländer added a comment - In the global Jenkins settings I have set "Prepare jobs environment" -> "Unset System Environment Variables" and I can confirm that this is causing the issue on my master node (why slave nodes are not affected remains unclear to me, the nodes have not specific setting regarding to environment variables). IMHO bat-steps should still work even if the "Unset System Environment Variables" option is set.

          Patrick Wolf added a comment -

          Can you reproduce this on the latest version of the durable task plugin?

          Patrick Wolf added a comment - Can you reproduce this on the latest version of the durable task plugin?

          Jesse Glick added a comment -

          gordin Are you using the EnvInject plugin? If so, disable it. At any rate, if there are steps to reproduce from scratch please let us know.

          Jesse Glick added a comment - gordin Are you using the EnvInject plugin? If so, disable it. At any rate, if there are steps to reproduce from scratch please let us know.

          Jesse Glick added a comment -

          One user reported similar symptoms which seem to have been caused by writing

          env.PATH = "${tool 'Maven 3'}/bin:${env.PATH}"
          

          rather than

          env.Path = "${tool 'Maven 3'}\\bin;${env.Path}"
          

          (The bad path separator : is the problem; the rest is stylistic.)

          An implementation of JENKINS-28718 would offer a cross-platform version of this idiom not susceptible to that mistake.

          At any rate, WindowsBatchScript could detect a node whose current %Path% lacks C:\Windows\System32 or generally does not seem to have an entry for cmd.exe, and report this misconfiguration more clearly.

          Jesse Glick added a comment - One user reported similar symptoms which seem to have been caused by writing env.PATH = "${tool 'Maven 3' }/bin:${env.PATH}" rather than env.Path = "${tool 'Maven 3' }\\bin;${env.Path}" (The bad path separator : is the problem; the rest is stylistic.) An implementation of JENKINS-28718 would offer a cross-platform version of this idiom not susceptible to that mistake. At any rate, WindowsBatchScript could detect a node whose current %Path% lacks C:\Windows\System32 or generally does not seem to have an entry for cmd.exe , and report this misconfiguration more clearly.

          Allen Fisher added a comment -

          I'm having the same issue that gordin is having, and the workaround he suggests works for now. This is a very vanilla installation with a fresh Windows 2012 machine. Something is very strange, I am running a powershell script and I had to pass the full path to powershell.exe in order to get Jenkins to find it. The system PATH has PowerShell in it so I'm not sure why that doesn't work either.

          Allen Fisher added a comment - I'm having the same issue that gordin is having, and the workaround he suggests works for now. This is a very vanilla installation with a fresh Windows 2012 machine. Something is very strange, I am running a powershell script and I had to pass the full path to powershell.exe in order to get Jenkins to find it. The system PATH has PowerShell in it so I'm not sure why that doesn't work either.

            jglick Jesse Glick
            gordin Christoph Vogtländer
            Votes:
            3 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: