Home → Problems →

core.autocrlf

• Edit

Kirill Müller

11 Aug, 2014 07:31 PM

It looks like Git is installed with the setting core.autocrlf true by default, which is overridden by the default appveyor.yml in the init section. Now, if a project provides its own appveyor.yml with its own init section, the default init section is not executed.

Would you consider configuring Git as core.autocrlf input by default, and not by the default appveyor.yml setting? I'm not sure how many existing projects this affects, though.

1. Support Staff 1 Posted by Feodor Fitsner on 11 Aug, 2014 08:16 PM

   

   Yeah, I think it could be safely switched to core.autocrlf input by default. Will do this during the next update.

   • Edit

2. 2 Posted by Kirill Müller on 11 Aug, 2014 09:52 PM

   

   Thanks!

   • Edit

3. 3 Posted by Hannu Hartikain... on 14 Aug, 2014 01:15 PM

   

   Just a heads up: changing this broke our build (due to coffeelint options). I did fix the problem by adjusting our settings, but it obviously took some time.

   This is not the first time our build is broken because of AppVeyor configuration changes (previously a development version of Node.js broke npm install), nor because AppVeyor breaks for some other reason on occasion (can't get a build agent, etc). It's too bad since our early impressions were good. Now many on our team are starting to think that AppVeyor is too unstable and we should change to another CI platform.

   • Edit

4. 4 Posted by dmcgee on 14 Aug, 2014 03:56 PM

   

   This just broke our build as well, not very cool at all, I spent a good 45 minutes this morning wondering how code that hasn't changed in 3 months suddenly stopped working. We had a literal string in a test, e.g.

   var myString = @"adsf
   new
   lines";
   

   And suddenly a test that was passing before because '/r/n' was present in the string and was being split correctly no longer works because the line ending has changed in the .cs source file.

   • Edit

5. Support Staff 5 Posted by Feodor Fitsner on 14 Aug, 2014 04:13 PM

   

   I though it's quite safe setting it to input as it doesn't change sources on checkout. The motivation was to make the environment more predictable. I'm really sorry I broke your builds and wasted your time for fixing that.

   At the same time I see the issue of communicating upcoming changes in build environment to the customers and I'm going to figure out a way to fix that.

   Will post an update here.

   • Edit

6. 6 Posted by Kirill Müller on 14 Aug, 2014 04:27 PM

   

   I'm sorry that the discussion I started breaks builds in the end. On the other hand, it seems that the code behaves differently depending on the value of a global setting -- I consider this unsafe, and this also could have happened on a developer's machine with a different value for that setting. There's also an xkcd version of what we have experienced here -- no offense intended ;-)

   • Edit

7. 7 Posted by Hannu Hartikain... on 15 Aug, 2014 06:05 AM

   

   I agree that code dependent on \r\n should never be converted to \n in VCS and I take the responsibility for that. The xkcd strip that Kirill posted does have a point. :)

   I just thought to point out to Feodor that, no matter how unreasonable, many devs tend to get agitated when something breaks and it's not directly their fault. Thanks for taking this seriously -- communication is key.

   • Edit

8. 8 Posted by micah on 22 Sep, 2014 05:33 AM

   

   Noting here that my build also broke and I spent about 30-45 minutes digging in to it before realizing the problem. I have since fixed my test to have well defined behavior regardless of file line endings.

   I just wanted to make sure that AppVeyor gets an idea of how many people were broken by this configuration change. This isn't the first time this has happened to me either, so it would be nice if there was some way to avoid this (I am not sure how, other than by making VM changes an opt-in sort of thing).

   • Edit

9. 9 Posted by Kirill Müller on 22 Sep, 2014 06:36 AM

   

   How about two versions of the VM -- "stable" where no changes are made, and "unstable" which can be changed. The choice of the VM could be a configuration item (.yml and/or GUI), to allow "opt-in". Sstable VMs are updated regularly but rarely (once a month or even less frequently) -- and their updates could be communicated.

   • Edit

10. Support Staff 10 Posted by Feodor Fitsner on 23 Sep, 2014 03:17 AM

    

    Very nice idea of having "stable" (default) and "unstable" versions of build worker image. Sounds much better than "test" that we currently use.

    Also, we are going to have another "technical" mailing list with quick and often updates of any scheduled maintenance or image changes.

    • Edit

11. 11 Posted by gep13 on 15 Oct, 2014 06:31 AM

    

    How would you subscribe to this mailing list? Or is it limited to only certain people?

    Thanks!

    • Edit

12. Support Staff 12 Posted by Feodor Fitsner on 15 Oct, 2014 04:49 PM

    

    It's not yet available, but we are planning to add subscribe/unsubscribe button to AppVeyor account UI.

    • Edit

13. 13 Posted by gep13 on 15 Oct, 2014 06:20 PM

    

    Cool, will keep an eye out for it!

    • Edit

14. Support Staff 14 Posted by Feodor Fitsner on 11 Dec, 2014 02:18 AM

    

    You can now subscribe to technical updates mailing list on Profile page: https://ci.appveyor.com/profile

    -Feodor

    • Edit

15. Ilya Finkelshteyn closed this discussion on 25 Aug, 2018 01:50 AM.