I have multiple jobs that use a Pipeline Script from SCM with git on a Windows machine. Some of these jobs build for Linux, and I need to set core.autocrlf=false before the git checkout. Other jobs build for Windows and require core.autocrlf=true to be set.
Setting core.autocrlf on a global or system scope won’t work because it affects all jobs. Is there a way to execute git config core.autocrlf false before git checkout is called? Or can I pass extra command line parameters to git, such as git -c core.autocrlf=false ...? Or any other ideas?
if you can I’d recommend setting the .gitattributes up in each repo, it’ll prevent the need to do it on everyones computers/agents.
Failing that, you should add that config globally to your agent, instead of doing it randomly per repo.
Lastly, I think there’s a property you can set on your scm settings that might let you configure those types of things, but i think first two are better.
Good tips. I have already tried the .gitattribute approach. But even though the build process needs the files with Unix line endings, there are developers who are developing on Windows and prefer checking out the sources with CRLF. Forcing everyone to LF caused some issues.
Now, I will try to create a separate agent on the same machine for the Linux builds, which will run under a different Windows user, allowing me to set the required Git configs on a global (user) level. Since I am not very familiar with Jenkins, I was hesitant to set up a controller/agent setup until now.
Just out of curiosity, do you know where I could override or add Git parameters for checkout in Jenkins? So far, I haven’t found anything. Basically, all I see is this:
There isn’t any way to override command line git parameters for checkout. Allowing that type of override would create even more complexity in the test and release process of the git plugin and the git client plugin and would block users from switching freely between JGit and command line git.
I recommend the .gitattributes technique suggested by @halkeye . It is the most likely to persist and most likely to work well for developers on all platforms. Text editors on Windows can be configured to use the line termination defined in the file. There are even automated formatters that will complain when incorrect line termination is used.
Having a mix of line termination styles in the repository makes it complicated for many people in many places. Choosing a line termination style and enforcing it with .gitattributes shifts the complexity onto the people who don’t want to comply with the selected line termination standard.
