I've got a Jenkins instance running on Windows and for one item, I need to check out from a CVS repository. As it is, the built-in CVS plugin for Jenkins is checking it out with Windows CRLF
line endings. However, some of what needs to be done requires that the files have Unix style LF
line endings.
Running a dos2unix
like utility over the entire repository seems painful to do safely and reliably.
I could use Cygwin's cvs to do it by running a shell script build step, but I would prefer something better integrated with Jenkins.
So, short of writing up a script to call an external CVS, or fixing it afterwards with dos2unix
, can Jenkins check out a CVS repository with Unix line endings on Windows?
I've since come across this bug report indicating that this issue has been known since 2012 and not much has been done about it. I'll leave the question open in case someone does know of an alternative to what I've already mentioned.
I've added dos2unix steps pretty often in my build scripts for windows (automake chain is very sensitive to this stuff), it might seem a bit ugly/fragile, but it's ok I think for a Jenkins build : if it breaks because of new files you'll get build issues.
In my experience, there are always a couple of platform specific steps in the build, so a bit of custom code to support windows seems ok.
An alternative might be to tag your files as "binary" on the CVS server (-kb flag) and make sure they are encoded correctly up there, this will avoid any transcoding at checkout time, but it seems more intrusive to me. I haven't actually used this for sources, I think it might mess the "diff" command.
A last idea might be to look more precisely at what tools are expecting the LF style endings on your win box, there might be mingW or windows versions you could deploy that support CRLF.
My vote still goes to the dos2unix solution overall.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With