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"

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: core
    • Labels:
    • Environment:
      Windows 2008 Server R2, Enterprise Edition, x64
    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

            bogdaniosif bogdaniosif created issue -
            Hide
            pjdarton 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"?

            Show
            pjdarton 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"?
            Hide
            bogdaniosif 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.

            Show
            bogdaniosif 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.
            Hide
            pjdarton 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.

            Show
            pjdarton 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.
            Hide
            bogdaniosif 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?

            Show
            bogdaniosif 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?
            Hide
            pjdarton 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.

            Show
            pjdarton 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.
            Hide
            yamabb 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

            Show
            yamabb 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
            bogdaniosif bogdaniosif made changes -
            Field Original Value New Value
            Link This issue is duplicated by JENKINS-9528 [ JENKINS-9528 ]
            bogdaniosif bogdaniosif made changes -
            Affects Version/s current [ 10162 ]
            Hide
            marnix_klooster 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.

            Show
            marnix_klooster 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.
            Hide
            marnix_klooster 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.

            Show
            marnix_klooster 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.
            Hide
            bogdaniosif 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.

            Show
            bogdaniosif 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.
            Hide
            marnix_klooster 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.

            Show
            marnix_klooster 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.
            Hide
            marnix_klooster 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?)

            Show
            marnix_klooster 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?)
            Hide
            andrey_x64 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.

            Show
            andrey_x64 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.
            Hide
            danielbeck 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...

            Show
            danielbeck 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...
            Hide
            andrey_x64 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.

            Show
            andrey_x64 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.
            Hide
            davidruhmann 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.

            Show
            davidruhmann 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 Oleg Nenashev made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            Hide
            oleg_nenashev Oleg Nenashev added a comment -
            Show
            oleg_nenashev Oleg Nenashev added a comment - David's PR: https://github.com/jenkinsci/jenkins/pull/1361
            davidruhmann David Ruhmann made changes -
            Assignee David Ruhmann [ davidruhmann ]
            Show
            davidruhmann David Ruhmann added a comment - New PR: https://github.com/jenkinsci/jenkins/pull/1370
            Hide
            scm_issue_link 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.

            Show
            scm_issue_link 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.
            scm_issue_link SCM/JIRA link daemon made changes -
            Status In Progress [ 3 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            dogfood 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
            Show
            dogfood 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
            danielbeck Daniel Beck made changes -
            Labels lts-candidate
            olivergondza Oliver Gondža made changes -
            Labels lts-candidate 1.580.1-fixed
            Hide
            scm_issue_link 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)

            Show
            scm_issue_link 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)
            Hide
            dogfood 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
            Show
            dogfood 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
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 137577 ] JNJira + In-Review [ 187574 ]

              People

              • Assignee:
                davidruhmann David Ruhmann
                Reporter:
                bogdaniosif bogdaniosif
              • Votes:
                6 Vote for this issue
                Watchers:
                11 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: