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

Wrong EOL (UNIX type: LF) in Windows batch files executed for build steps of type "Execute Windows batch command"

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • Windows 2008 Server R2, Enterprise Edition, x64

      For a build step of type "Execute Windows batch command" Hudson generates and then executes a .bat file using the content provided by the user in the configuration textbox of the step.

      The problem is that the generated .bat file has UNIX style EOL (lines ending with LF) and the Windows Command Interpreter (CMD.EXE) requires Windows style EOLs (lines ending with CR LF) in batches, in order to interpret them correctly.

      The consequences of having UNIX style EOL in Windows batches is undetermined. Very simple batches work while more complex ones will behave erratically because CMD.EXE will consume multiple lines in one command and it will fail to find some labels.

          [JENKINS-7478] Wrong EOL (UNIX type: LF) in Windows batch files executed for build steps of type "Execute Windows batch command"

          pjdarton added a comment -

          I don't find that this is the case here - in a 100% Windows environment.
          I'm not saying that it isn't possible to have this problem, but it isn't universal. My guess is that you'd need a mixed environment with some parts of Hudson working with unix EOLs and some with Windows EOLs.

          e.g. Is your Hudson server on a unix machine, with the slave on Windows?
          e.g. Or maybe you used a browser on a unix machine and Hudson simply saved the unix-EOLed data "as is"?

          pjdarton added a comment - I don't find that this is the case here - in a 100% Windows environment. I'm not saying that it isn't possible to have this problem, but it isn't universal. My guess is that you'd need a mixed environment with some parts of Hudson working with unix EOLs and some with Windows EOLs. e.g. Is your Hudson server on a unix machine, with the slave on Windows? e.g. Or maybe you used a browser on a unix machine and Hudson simply saved the unix-EOLed data "as is"?

          bogdaniosif added a comment -

          100% Windows environment for me too. I only have one server instance, no slaves, version 1.374. Hudson runs in the JBoss AS v4.2 container with default configurations. Maybe the issue is brought about by the container. I know very little about Java apps and servers so I can't easily tell why this happens.

          I'm looking on disk at the config.xml file of my jobs and see that it is also saved with UNIX style EOL. The commands for any given step of type "Execute Windows batch command" are stored in nodes of this config.xml file. I think the UNIX style EOL of the config.xml file is related to the fact that the generated .bat files also have UNIX style EOL. I did all the configurations through the Hudson UI, no tinkering directly with the XML files.

          bogdaniosif added a comment - 100% Windows environment for me too. I only have one server instance, no slaves, version 1.374. Hudson runs in the JBoss AS v4.2 container with default configurations. Maybe the issue is brought about by the container. I know very little about Java apps and servers so I can't easily tell why this happens. I'm looking on disk at the config.xml file of my jobs and see that it is also saved with UNIX style EOL. The commands for any given step of type "Execute Windows batch command" are stored in nodes of this config.xml file. I think the UNIX style EOL of the config.xml file is related to the fact that the generated .bat files also have UNIX style EOL. I did all the configurations through the Hudson UI, no tinkering directly with the XML files.

          pjdarton added a comment -

          I'm using Apache Tomcat here, with one server (that only acts as a server) and many slaves. It may be that it's JBoss that's triggering this issue.

          I suspect that you are correct that it's the EOL style of the confix.xml file that's the root of your problem.
          Try closing Hudson down, converting that file from unix-EOL to MSDOS-EOL and then restart everything - that'll probably fix it (keep a backup of the file, just in case).

          If that does, then that (a) gives you a workaround and (b) suggests that there is a real bug in Hudson/Jenkins (which probably isn't seen by anyone who doesn't use JBoss), as it really ought to ensure that all EOLs are MSDOS-EOLs for the batch command task.

          pjdarton added a comment - I'm using Apache Tomcat here, with one server (that only acts as a server) and many slaves. It may be that it's JBoss that's triggering this issue. I suspect that you are correct that it's the EOL style of the confix.xml file that's the root of your problem. Try closing Hudson down, converting that file from unix-EOL to MSDOS-EOL and then restart everything - that'll probably fix it (keep a backup of the file, just in case). If that does, then that (a) gives you a workaround and (b) suggests that there is a real bug in Hudson/Jenkins (which probably isn't seen by anyone who doesn't use JBoss), as it really ought to ensure that all EOLs are MSDOS-EOLs for the batch command task.

          bogdaniosif added a comment - - edited

          I created a new Hudson project with a single build step of type "Execute Windows batch command".

          Here is how the relevant part of its config.xml looks like (I added the '<<<LF>>>' and '.....' parts):
          .....
          <builders>"Execute Windows batch command"<<<LF>>>
          <hudson.tasks.BatchFile><<<LF>>>
          <command>c:\temp\Sleep.exe 30<<<LF>>>
          c:\temp\Sleep.exe 30<<<LF>>>
          c:\temp\Sleep.exe 30<<<LF>>>
          </command><<<LF>>>
          </hudson.tasks.BatchFile><<<LF>>>
          </builders><<<LF>>>
          .....

          The config was edited from the Hudson Web UI, using FF 3.6.14 on Win7 x86-64, and config.xml was saved by Hudson with UNIX style EOL, as I tried to represent above using '<<<LF>>>'.

          When the .bat for the above build step is generated it looks like this:
          c:\temp\Sleep.exe 30<<<LF>>>
          c:\temp\Sleep.exe 30<<<LF>>>
          c:\temp\Sleep.exe 30<<<LF>>>
          <<<CR>>><<<LF>>>
          exit %ERRORLEVEL%

          Note that the generated .bat file would be correct if the step would consist in just a single line. I think this is actually the core of the problem. The developer who wrote the code that generates the .bat file assumed that the step would only ever consist in one line so he added the '<<<CR>>><<<LF>>>' and 'exit %ERRORLEVEL%' to what is stored in the step's node from config.xml.

          However, the assumption is not enforced by the Hudson UI which allows multiline editing for this type of step.

          I think it would be good for people running Hudson on Windows to be allowed to write batch scripts consisting in multiple lines on these type of steps. The way to do it would involve modifying the code generating the .bat file to replace all '<<<LF>>>' occurences with '<<<CR>>><<<LF>>>', IF they are not already preceeded by a '<<<CR>>>'.

          I also tried to stop Hudson, convert the config.xml EOL to Windows and then restart Hudson. Unfortunately, the generated .bat is still the same. This probably has something to do with the Java classes used to represent the .xml file. Also, if any change is made on the job configuration from the Hudson Web UI, when the config is saved, it is again saved with UNIX style EOL.

          If you are running Tomcat on Windows, and you edit your jobs configs via the Hudson Web UI, what is the type of EOL that your config.xml files have?

          bogdaniosif added a comment - - edited I created a new Hudson project with a single build step of type "Execute Windows batch command". Here is how the relevant part of its config.xml looks like (I added the '<<<LF>>>' and '.....' parts): ..... <builders>"Execute Windows batch command"<<<LF>>> <hudson.tasks.BatchFile><<<LF>>> <command>c:\temp\Sleep.exe 30<<<LF>>> c:\temp\Sleep.exe 30<<<LF>>> c:\temp\Sleep.exe 30<<<LF>>> </command><<<LF>>> </hudson.tasks.BatchFile><<<LF>>> </builders><<<LF>>> ..... The config was edited from the Hudson Web UI, using FF 3.6.14 on Win7 x86-64, and config.xml was saved by Hudson with UNIX style EOL, as I tried to represent above using '<<<LF>>>'. When the .bat for the above build step is generated it looks like this: c:\temp\Sleep.exe 30<<<LF>>> c:\temp\Sleep.exe 30<<<LF>>> c:\temp\Sleep.exe 30<<<LF>>> <<<CR>>><<<LF>>> exit %ERRORLEVEL% Note that the generated .bat file would be correct if the step would consist in just a single line. I think this is actually the core of the problem. The developer who wrote the code that generates the .bat file assumed that the step would only ever consist in one line so he added the '<<<CR>>><<<LF>>>' and 'exit %ERRORLEVEL%' to what is stored in the step's node from config.xml. However, the assumption is not enforced by the Hudson UI which allows multiline editing for this type of step. I think it would be good for people running Hudson on Windows to be allowed to write batch scripts consisting in multiple lines on these type of steps. The way to do it would involve modifying the code generating the .bat file to replace all '<<<LF>>>' occurences with '<<<CR>>><<<LF>>>', IF they are not already preceeded by a '<<<CR>>>'. I also tried to stop Hudson, convert the config.xml EOL to Windows and then restart Hudson. Unfortunately, the generated .bat is still the same. This probably has something to do with the Java classes used to represent the .xml file. Also, if any change is made on the job configuration from the Hudson Web UI, when the config is saved, it is again saved with UNIX style EOL. If you are running Tomcat on Windows, and you edit your jobs configs via the Hudson Web UI, what is the type of EOL that your config.xml files have?

          pjdarton added a comment -

          I am running Tomcat on Windows (XP).
          Both my main hudson config.xml and all my job config.xml files are "unix ansi" (according to Notepad++), i.e. they're using unix EOLs.
          I've just checked the contents of a couple of the .bat files that Hudson puts in the temp directory (e.g. C:\Documents and Settings\myusername\Local Settings\Temp\hudson1234567890123456789.bat) and I can confirm that, on my system at least, these files have MSDOS line endings, including those which contain more than one command before the <cr><lf>exit %ERRORLEVEL% bit at the end.
          e.g. my file

          {hudson8875928727532406690.bat}

          contains

          @echo.Rebooting %NodeName% aka %COMPUTERNAME%<cr><lf>
          @shutdown /r /t 5 /d p:4:5 /c "%RebootReason%"<cr><lf>
          @echo.Shutdown in 5 seconds.<cr><lf>
          @ping -t 127.0.0.1 >NUL<cr><lf>
          exit %ERRORLEVEL%

          In my "job" config.xml, the <hudson.tasks.BatchFile> element containing that build step is as follows (where <lf> is a real linefeed, rather than the characters < l f and >)

              <hudson.tasks.BatchFile><lf>
                <command>@echo.Rebooting %NodeName% aka %COMPUTERNAME%&#xd;<lf>
          @shutdown /r /t 5 /d p:4:5 /c &quot;%RebootReason%&quot;&#xd;<lf>
          @echo.Shutdown in 5 seconds.&#xd;<lf>
          @ping -t 127.0.0.1 &gt;NUL</command><lf>
              </hudson.tasks.BatchFile><lf>

          Some of the <command> elements end with a (unix) EOL and hence have their </command> bit on the start of a new line (as in the example above), whereas others have the </command> at the end of the last command line.

          pjdarton added a comment - I am running Tomcat on Windows (XP). Both my main hudson config.xml and all my job config.xml files are "unix ansi" (according to Notepad++), i.e. they're using unix EOLs. I've just checked the contents of a couple of the .bat files that Hudson puts in the temp directory (e.g. C:\Documents and Settings\myusername\Local Settings\Temp\hudson1234567890123456789.bat ) and I can confirm that, on my system at least, these files have MSDOS line endings, including those which contain more than one command before the <cr><lf>exit %ERRORLEVEL% bit at the end. e.g. my file {hudson8875928727532406690.bat} contains @echo.Rebooting %NodeName% aka %COMPUTERNAME%<cr><lf> @shutdown /r /t 5 /d p:4:5 /c "%RebootReason%"<cr><lf> @echo.Shutdown in 5 seconds.<cr><lf> @ping -t 127.0.0.1 >NUL<cr><lf> exit %ERRORLEVEL% In my "job" config.xml, the <hudson.tasks.BatchFile> element containing that build step is as follows (where <lf> is a real linefeed, rather than the characters < l f and >) <hudson.tasks.BatchFile><lf> <command>@echo.Rebooting %NodeName% aka %COMPUTERNAME%&#xd;<lf> @shutdown /r /t 5 /d p:4:5 /c &quot;%RebootReason%&quot;&#xd;<lf> @echo.Shutdown in 5 seconds.&#xd;<lf> @ping -t 127.0.0.1 &gt;NUL</command><lf> </hudson.tasks.BatchFile><lf> Some of the <command> elements end with a (unix) EOL and hence have their </command> bit on the start of a new line (as in the example above), whereas others have the </command> at the end of the last command line.

          Yama Tksh added a comment - - edited

          In our case, this problem seems to occur (only?) when batch script text includes multibyte characters, for example:

          @echo "deleting 古いファイル。。。" 

          When updated job config using Firefox(3.6), each line-end of <command> in config.xml does not include &#xd;,and the generated .bat file is only LF.
          I suppose,however,Windows batch execution seems to work well even in such a case as long as no multibyte character exists.

          OTOH, when using IE8, each line of <command> ends with &#xd; and the generated .bat file is CRLF.
          And execution seems to work well even when some multibyte characters are included.

          A japanese person blogged the multibyte character problem on 2010-09-29, but is this already fixed ??
          http://d.hatena.ne.jp/miau/20100929/1285768041

          Our environment: Jenkins 1.410 on CentOS 5.6, and Windows XP JNLP slave

          Yama Tksh added a comment - - edited In our case, this problem seems to occur (only?) when batch script text includes multibyte characters, for example: @echo "deleting 古いファイル。。。" When updated job config using Firefox(3.6), each line-end of <command> in config.xml does not include &#xd;,and the generated .bat file is only LF. I suppose,however, Windows batch execution seems to work well even in such a case as long as no multibyte character exists . OTOH, when using IE8, each line of <command> ends with &#xd; and the generated .bat file is CRLF. And execution seems to work well even when some multibyte characters are included. A japanese person blogged the multibyte character problem on 2010-09-29, but is this already fixed ?? http://d.hatena.ne.jp/miau/20100929/1285768041 Our environment: Jenkins 1.410 on CentOS 5.6, and Windows XP JNLP slave

          We are also bitten by this issue, using Jenkins 1.409.2 on Windows Server 2008 R2. We are not using any multibyte characters. We observe that when using a multi-line command in 'Execute Windows batch command', occasionally only the first line is executed. Here is an example. Using the following multi-line command:

          copy upstream\*.properties .
          upstream\tests.bat
          

          Sometimes this results in the following:

          05:01:01  [Performance-nlbavwiregtest-Run-Tests] $ cmd /c call C:\Users\ADMINI~1\AppData\Local\Temp\3\hudson5007144748370114365.bat
          05:01:01  
          05:01:01  c:\jenkins-slave\workspace\Performance-nlbavwiregtest-Run-Tests>copy upstream\*.properties . 
          05:01:01  upstream\ConnectTests.properties
          05:01:01  upstream\ProcessTests.properties
          05:01:01          2 file(s) copied.
          05:01:01  
          05:01:01  c:\jenkins-slave\workspace\Performance-nlbavwiregtest-Run-Tests>upstream\tests.bat
          05:01:01  Recording fingerprints
          

          Here you see that cmd.exe sees the second line, but does not run it; otherwise the tests.bat file would have generated more output, before the 'Recording fingerprints' line.

          This happens occasionally, i.e., without changing anything to the job configuration or any source file, one build doesn't work and the next one does.

          As suggested in a previous comment, manually editing the (UNIX-line-endings) config.xml file, by putting at the end of every line inside the <hudson.tasks.BatchFile> <command>, makes the problem go away.

          Marnix Klooster added a comment - We are also bitten by this issue, using Jenkins 1.409.2 on Windows Server 2008 R2. We are not using any multibyte characters. We observe that when using a multi-line command in 'Execute Windows batch command', occasionally only the first line is executed. Here is an example. Using the following multi-line command: copy upstream\*.properties . upstream\tests.bat Sometimes this results in the following: 05:01:01 [Performance-nlbavwiregtest-Run-Tests] $ cmd /c call C:\Users\ADMINI~1\AppData\Local\Temp\3\hudson5007144748370114365.bat 05:01:01 05:01:01 c:\jenkins-slave\workspace\Performance-nlbavwiregtest-Run-Tests>copy upstream\*.properties . 05:01:01 upstream\ConnectTests.properties 05:01:01 upstream\ProcessTests.properties 05:01:01 2 file(s) copied. 05:01:01 05:01:01 c:\jenkins-slave\workspace\Performance-nlbavwiregtest-Run-Tests>upstream\tests.bat 05:01:01 Recording fingerprints Here you see that cmd.exe sees the second line, but does not run it; otherwise the tests.bat file would have generated more output, before the 'Recording fingerprints' line. This happens occasionally, i.e., without changing anything to the job configuration or any source file, one build doesn't work and the next one does. As suggested in a previous comment, manually editing the (UNIX-line-endings) config.xml file, by putting at the end of every line inside the <hudson.tasks.BatchFile> <command> , makes the problem go away.

          I just found a workaround, which is to use the following cmd.exe syntax (which seems to be really poorly documented):

          copy upstream\*.properties . && upstream\tests.bat
          

          However, I have a multi-line command for which this does not work:

          robocopy ...imagine arguments here...
          if errorlevel 1 exit /b 0
          exit /b 1 
          

          It seems that a list of &&-connected commands breaks off at a non-zero exit code, and Robocopy in the normal case sets exit code (ERRORLEVEL) 1, which would make Jenkins think (incorrectly) that something went wrong.

          Marnix Klooster added a comment - I just found a workaround, which is to use the following cmd.exe syntax (which seems to be really poorly documented): copy upstream\*.properties . && upstream\tests.bat However, I have a multi-line command for which this does not work: robocopy ...imagine arguments here... if errorlevel 1 exit /b 0 exit /b 1 It seems that a list of && -connected commands breaks off at a non-zero exit code, and Robocopy in the normal case sets exit code (ERRORLEVEL) 1, which would make Jenkins think (incorrectly) that something went wrong.

          bogdaniosif added a comment -

          I wouldn't call your solution a workaround since you just try to fit in the simplest possible usage for this type of Jenkins build step: single line scripts. We already know that these work.

          This is off topic but if you really really want to, you can solve the robocopy problem on one line like this:

          ((robocopy ...imagine arguments here...) && (exit /b 0)) || (if errorlevel 1 (exit /b 0) else (exit /b 1))
          

          AFAIK, the operators &&, ||, &, |, >, < are no longer documented in the Windows help system since Vista. You can find all the dirty details here: http://technet.microsoft.com/en-us/library/bb490954.aspx One can do a surprising amount of things in CMD batch files but it's not pretty and you can cut yourself very easily so beware.

          bogdaniosif added a comment - I wouldn't call your solution a workaround since you just try to fit in the simplest possible usage for this type of Jenkins build step: single line scripts. We already know that these work. This is off topic but if you really really want to, you can solve the robocopy problem on one line like this: ((robocopy ...imagine arguments here...) && (exit /b 0)) || (if errorlevel 1 (exit /b 0) else (exit /b 1)) AFAIK, the operators &&, ||, &, |, >, < are no longer documented in the Windows help system since Vista. You can find all the dirty details here: http://technet.microsoft.com/en-us/library/bb490954.aspx One can do a surprising amount of things in CMD batch files but it's not pretty and you can cut yourself very easily so beware.

          @bogdaniosif Agreed it's not much of a workaround, it's more 'patient: it hurts when I do that; doctor: then don't do that!' But thanks for the off-topic response on Robocopy, that really helps me.

          Marnix Klooster added a comment - @ bogdaniosif Agreed it's not much of a workaround, it's more 'patient: it hurts when I do that; doctor: then don't do that!' But thanks for the off-topic response on Robocopy, that really helps me.

          I'd like to dig into this issue sometime, and create a fix for this. Is there anyone who can point me to the best place(s) in the source to fix this? (Or is someone already actively working on this?)

          Marnix Klooster added a comment - I'd like to dig into this issue sometime, and create a fix for this. Is there anyone who can point me to the best place(s) in the source to fix this? (Or is someone already actively working on this?)

          I vote this issue up because chaining commands with '&&' looks at least strange and results in batch scripts nearly as readable as a base64-encoded RSA public key block.

          Andrey Rogozhnikov added a comment - I vote this issue up because chaining commands with '&&' looks at least strange and results in batch scripts nearly as readable as a base64-encoded RSA public key block.

          Daniel Beck added a comment -

          Does this issue still occur for anyone in recent Jenkins versions? I have never experienced this on Jenkins 1.415 and newer...

          Daniel Beck added a comment - Does this issue still occur for anyone in recent Jenkins versions? I have never experienced this on Jenkins 1.415 and newer...

          Still have this issue on 1.556.
          The exact script is http://rand.org.ru/upload/hudson2498629865472256615.bat. The slave system information is http://pastebin.com/xL47Vz3g. The master is running under Linux.

          Andrey Rogozhnikov added a comment - Still have this issue on 1.556. The exact script is http://rand.org.ru/upload/hudson2498629865472256615.bat . The slave system information is http://pastebin.com/xL47Vz3g . The master is running under Linux.

          David Ruhmann added a comment - - edited

          Still have this issue on 1.563
          Using Firefox 29 and Chrome 34 the

          &#xd;

          character does not get written out. Only when using IE (11 in my case) does it write out correctly.

          So it would seem that Jenkins is not compatible with Firefox or Chrome.

          David Ruhmann added a comment - - edited Still have this issue on 1.563 Using Firefox 29 and Chrome 34 the &#xd; character does not get written out. Only when using IE (11 in my case) does it write out correctly. So it would seem that Jenkins is not compatible with Firefox or Chrome.

          Oleg Nenashev added a comment -

          Oleg Nenashev added a comment - David's PR: https://github.com/jenkinsci/jenkins/pull/1361

          David Ruhmann added a comment -

          David Ruhmann added a comment - New PR: https://github.com/jenkinsci/jenkins/pull/1370

          Code changed in jenkins
          User: David Ruhmann
          Path:
          core/src/main/java/hudson/tasks/BatchFile.java
          core/src/main/java/hudson/tasks/Shell.java
          core/src/main/java/hudson/tools/AbstractCommandInstaller.java
          core/src/main/java/hudson/tools/BatchCommandInstaller.java
          core/src/main/java/hudson/tools/CommandInstaller.java
          core/src/main/java/hudson/util/LineEndingConversion.java
          test/src/test/java/hudson/tasks/BatchFileTest.java
          test/src/test/java/hudson/tasks/ShellTest.java
          test/src/test/java/hudson/tools/BatchCommandInstallerTest.java
          test/src/test/java/hudson/tools/CommandInstallerTest.java
          test/src/test/java/hudson/util/LineEndingConversionTest.java
          http://jenkins-ci.org/commit/jenkins/67ac47af0709dde6297dffeb210b03d8b65f6033
          Log:
          [FIXED JENKINS-7478]

          Create Line Ending Conversion utility to convert scripts to proper OS
          line ending type. Tests included.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: David Ruhmann Path: core/src/main/java/hudson/tasks/BatchFile.java core/src/main/java/hudson/tasks/Shell.java core/src/main/java/hudson/tools/AbstractCommandInstaller.java core/src/main/java/hudson/tools/BatchCommandInstaller.java core/src/main/java/hudson/tools/CommandInstaller.java core/src/main/java/hudson/util/LineEndingConversion.java test/src/test/java/hudson/tasks/BatchFileTest.java test/src/test/java/hudson/tasks/ShellTest.java test/src/test/java/hudson/tools/BatchCommandInstallerTest.java test/src/test/java/hudson/tools/CommandInstallerTest.java test/src/test/java/hudson/util/LineEndingConversionTest.java http://jenkins-ci.org/commit/jenkins/67ac47af0709dde6297dffeb210b03d8b65f6033 Log: [FIXED JENKINS-7478] Create Line Ending Conversion utility to convert scripts to proper OS line ending type. Tests included.

          Code changed in jenkins
          User: Daniel Beck
          Path:
          core/src/main/java/hudson/tasks/BatchFile.java
          core/src/main/java/hudson/tasks/Shell.java
          core/src/main/java/hudson/tools/AbstractCommandInstaller.java
          core/src/main/java/hudson/tools/BatchCommandInstaller.java
          core/src/main/java/hudson/tools/CommandInstaller.java
          core/src/main/java/hudson/util/LineEndingConversion.java
          test/src/test/java/hudson/tasks/BatchFileTest.java
          test/src/test/java/hudson/tasks/ShellTest.java
          test/src/test/java/hudson/tools/BatchCommandInstallerTest.java
          test/src/test/java/hudson/tools/CommandInstallerTest.java
          test/src/test/java/hudson/util/LineEndingConversionTest.java
          http://jenkins-ci.org/commit/jenkins/3d25f57aa1352359331675c05cd387e6bc536a3a
          Log:
          Merge pull request #1370 from DavidRuhmann/JENKINS-7478

          [FIXED JENKINS-7478] Correct Line Endings for Batch Files

          Compare: https://github.com/jenkinsci/jenkins/compare/8bb88be27ec4...3d25f57aa135

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Daniel Beck Path: core/src/main/java/hudson/tasks/BatchFile.java core/src/main/java/hudson/tasks/Shell.java core/src/main/java/hudson/tools/AbstractCommandInstaller.java core/src/main/java/hudson/tools/BatchCommandInstaller.java core/src/main/java/hudson/tools/CommandInstaller.java core/src/main/java/hudson/util/LineEndingConversion.java test/src/test/java/hudson/tasks/BatchFileTest.java test/src/test/java/hudson/tasks/ShellTest.java test/src/test/java/hudson/tools/BatchCommandInstallerTest.java test/src/test/java/hudson/tools/CommandInstallerTest.java test/src/test/java/hudson/util/LineEndingConversionTest.java http://jenkins-ci.org/commit/jenkins/3d25f57aa1352359331675c05cd387e6bc536a3a Log: Merge pull request #1370 from DavidRuhmann/ JENKINS-7478 [FIXED JENKINS-7478] Correct Line Endings for Batch Files Compare: https://github.com/jenkinsci/jenkins/compare/8bb88be27ec4...3d25f57aa135

          dogfood added a comment -

          Integrated in jenkins_main_trunk #3687
          [FIXED JENKINS-7478] (Revision 67ac47af0709dde6297dffeb210b03d8b65f6033)

          Result = SUCCESS
          david.ruhmann : 67ac47af0709dde6297dffeb210b03d8b65f6033
          Files :

          • test/src/test/java/hudson/util/LineEndingConversionTest.java
          • test/src/test/java/hudson/tools/BatchCommandInstallerTest.java
          • core/src/main/java/hudson/tools/BatchCommandInstaller.java
          • test/src/test/java/hudson/tools/CommandInstallerTest.java
          • core/src/main/java/hudson/tasks/Shell.java
          • test/src/test/java/hudson/tasks/ShellTest.java
          • core/src/main/java/hudson/util/LineEndingConversion.java
          • core/src/main/java/hudson/tasks/BatchFile.java
          • core/src/main/java/hudson/tools/CommandInstaller.java
          • core/src/main/java/hudson/tools/AbstractCommandInstaller.java
          • test/src/test/java/hudson/tasks/BatchFileTest.java

          dogfood added a comment - Integrated in jenkins_main_trunk #3687 [FIXED JENKINS-7478] (Revision 67ac47af0709dde6297dffeb210b03d8b65f6033) Result = SUCCESS david.ruhmann : 67ac47af0709dde6297dffeb210b03d8b65f6033 Files : test/src/test/java/hudson/util/LineEndingConversionTest.java test/src/test/java/hudson/tools/BatchCommandInstallerTest.java core/src/main/java/hudson/tools/BatchCommandInstaller.java test/src/test/java/hudson/tools/CommandInstallerTest.java core/src/main/java/hudson/tasks/Shell.java test/src/test/java/hudson/tasks/ShellTest.java core/src/main/java/hudson/util/LineEndingConversion.java core/src/main/java/hudson/tasks/BatchFile.java core/src/main/java/hudson/tools/CommandInstaller.java core/src/main/java/hudson/tools/AbstractCommandInstaller.java test/src/test/java/hudson/tasks/BatchFileTest.java

          Code changed in jenkins
          User: David Ruhmann
          Path:
          core/src/main/java/hudson/tasks/BatchFile.java
          core/src/main/java/hudson/tasks/Shell.java
          core/src/main/java/hudson/tools/AbstractCommandInstaller.java
          core/src/main/java/hudson/tools/BatchCommandInstaller.java
          core/src/main/java/hudson/tools/CommandInstaller.java
          core/src/main/java/hudson/util/LineEndingConversion.java
          test/src/test/java/hudson/tasks/BatchFileTest.java
          test/src/test/java/hudson/tasks/ShellTest.java
          test/src/test/java/hudson/tools/BatchCommandInstallerTest.java
          test/src/test/java/hudson/tools/CommandInstallerTest.java
          test/src/test/java/hudson/util/LineEndingConversionTest.java
          http://jenkins-ci.org/commit/jenkins/efae48a451b1dbb15a13abff26b0bec269a63909
          Log:
          [FIXED JENKINS-7478]

          Create Line Ending Conversion utility to convert scripts to proper OS
          line ending type. Tests included.

          (cherry picked from commit 67ac47af0709dde6297dffeb210b03d8b65f6033)

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: David Ruhmann Path: core/src/main/java/hudson/tasks/BatchFile.java core/src/main/java/hudson/tasks/Shell.java core/src/main/java/hudson/tools/AbstractCommandInstaller.java core/src/main/java/hudson/tools/BatchCommandInstaller.java core/src/main/java/hudson/tools/CommandInstaller.java core/src/main/java/hudson/util/LineEndingConversion.java test/src/test/java/hudson/tasks/BatchFileTest.java test/src/test/java/hudson/tasks/ShellTest.java test/src/test/java/hudson/tools/BatchCommandInstallerTest.java test/src/test/java/hudson/tools/CommandInstallerTest.java test/src/test/java/hudson/util/LineEndingConversionTest.java http://jenkins-ci.org/commit/jenkins/efae48a451b1dbb15a13abff26b0bec269a63909 Log: [FIXED JENKINS-7478] Create Line Ending Conversion utility to convert scripts to proper OS line ending type. Tests included. (cherry picked from commit 67ac47af0709dde6297dffeb210b03d8b65f6033)

          dogfood added a comment -

          Integrated in jenkins_main_trunk #4292
          [FIXED JENKINS-7478] (Revision efae48a451b1dbb15a13abff26b0bec269a63909)

          Result = UNSTABLE
          ogondza : efae48a451b1dbb15a13abff26b0bec269a63909
          Files :

          • test/src/test/java/hudson/tools/CommandInstallerTest.java
          • core/src/main/java/hudson/tasks/BatchFile.java
          • core/src/main/java/hudson/tasks/Shell.java
          • test/src/test/java/hudson/tasks/BatchFileTest.java
          • core/src/main/java/hudson/tools/CommandInstaller.java
          • test/src/test/java/hudson/tools/BatchCommandInstallerTest.java
          • core/src/main/java/hudson/tools/BatchCommandInstaller.java
          • test/src/test/java/hudson/util/LineEndingConversionTest.java
          • test/src/test/java/hudson/tasks/ShellTest.java
          • core/src/main/java/hudson/util/LineEndingConversion.java
          • core/src/main/java/hudson/tools/AbstractCommandInstaller.java

          dogfood added a comment - Integrated in jenkins_main_trunk #4292 [FIXED JENKINS-7478] (Revision efae48a451b1dbb15a13abff26b0bec269a63909) Result = UNSTABLE ogondza : efae48a451b1dbb15a13abff26b0bec269a63909 Files : test/src/test/java/hudson/tools/CommandInstallerTest.java core/src/main/java/hudson/tasks/BatchFile.java core/src/main/java/hudson/tasks/Shell.java test/src/test/java/hudson/tasks/BatchFileTest.java core/src/main/java/hudson/tools/CommandInstaller.java test/src/test/java/hudson/tools/BatchCommandInstallerTest.java core/src/main/java/hudson/tools/BatchCommandInstaller.java test/src/test/java/hudson/util/LineEndingConversionTest.java test/src/test/java/hudson/tasks/ShellTest.java core/src/main/java/hudson/util/LineEndingConversion.java core/src/main/java/hudson/tools/AbstractCommandInstaller.java

            davidruhmann David Ruhmann
            bogdaniosif bogdaniosif
            Votes:
            6 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: