search

sous-chefs / powershell

Development repository for the powershell cookbook
https://supermarket.chef.io/cookbooks/powershell
Apache License 2.0
110 stars 88 forks source link

Override Appveyor line ending settings, use CRLF on Windows #113

Closed stuartpreston closed 7 years ago

stuartpreston commented 7 years ago

Signed-off-by: Stuart Preston stuart@chef.io

Description

Allows Appveyor builds to honor the correct line ending for Windows, when built on Windows

Check List

smurawski commented 7 years ago

I think this is fixing the problem in the wrong place. If rubocop is finding problems when there are linux line endings on files on Windows, then rubocop has the problem. I've long been advocating that if developing on Windows, we should default to LF line endings so that things like kitchen, vagrant, and docker would all play nice.

stuartpreston commented 7 years ago

My experience has been that teams developing on Windows set themselves up to use Git with "auto" line ending settings. This is the official guidance from GitHub and I've tended to roll with it. For the most part this is what teams want when running on Windows. Especially for templated/generated files, connection string files/UDL files, .ini config files and Visual Studio (pre-2015) projects on Windows.

I don't see a problem with the way Rubocop works here specifically. On Linux it expects Unix line endings and on Windows the tool expects Windows line endings. To me this is reasonable behavior, but I agree a better behavior would be to detect a line ending irrespective of platform.

The problem with Appveyor specifically is that it forces Unix line endings when checking out from Git becuase there is no global setting specifying the line endings and is a Windows build system, hence the Rubocop tooling complaining. This commit makes Appveyor behave like a typical Windows ChefDK machine by following the default Windows guidance for configuring Git correctly.

smurawski commented 7 years ago

The problem (to me) is if you build and publish a gem or cookbook on Windows, there is a strong chance the use of that gem or cookbook on an Mac or Linux will break. This isn't really as much a Windows problem, but the intolerance of tools on other platforms for differing line endings.

While this may be the official guidance, it limits the effectiveness of a Windows development environment in a cross platform world.

stuartpreston commented 7 years ago

I just had to check on a Mac and find a gem I've published from Windows to see you are 100% correct in that the gem has kept the original line endings from the platform I published from, which is what I expected:

Stuarts-MacBook-Pro:Downloads stuartpreston$ gem unpack ./kitchen-azurerm-0.11.0.gem
Unpacked gem: '/Users/stuartpreston/Downloads/kitchen-azurerm-0.11.0'
Stuarts-MacBook-Pro:Downloads stuartpreston$ cd kitchen-azurerm-0.11.0
Stuarts-MacBook-Pro:kitchen-azurerm-0.11.0 stuartpreston$ ls
CHANGELOG.md    LICENSE     README.md   lib     templates
Stuarts-MacBook-Pro:kitchen-azurerm-0.11.0 stuartpreston$ file README.md
README.md: UTF-8 Unicode text, with very long lines, with CRLF line terminators

However, this has not been a specific problem for me, many people are using this driver successfully on macOS and Linux.

Are you suggesting filing an issue with Rubocop and asking them (and all other linting tools vendors) to treat LF as CRLF when on Windows, and via Git settings force the use of LF (autocrlf = input) instead of CRLF when running on both Windows and Mac?

smurawski commented 7 years ago

@stuartpreston Yep. Until recently (maybe earlier this spring), rubocop didn't care about line endings in this scenario. It's only recently that I've seen the behavior change.

And I have broken test-kitchen releases by shipping the gem from my windows machine in the past (there should be an pr to bump the version from that from about a year or so ago).

stuartpreston commented 7 years ago

@smurawski Yeah I was just reading this. https://github.com/bbatsov/rubocop/issues/4293 - we can now specify the specific line ends we choose using the following directive:

  Style/EndOfLine:
  EnforcedStyle: lf

The tool's default behaviour is how I would expect it to be, and the only place we have an issue is Appveyor specifically because it forces LF line endings from Git by default (no core.autocrlf=true setting). I've gotta be honest though, I am still -1 on telling every Windows user to globally configure their machine for LF line endings and think we should look at the generators instead (i.e. adding a text eol=lf line to the .gitattributes file).

smurawski commented 7 years ago

I understand your point on the global setting, but I recommend it for folks who have to work cross platform. It just cuts out one major corner case in so many unix-flavored tool chains and most Windows stuff doesn't care.

stuartpreston commented 7 years ago

OK, I'll unapprove this and resubmit this as a Rubocop config fix and .gitattributes change to force LF on all platforms. Thanks.

smurawski commented 7 years ago

For reference - https://github.com/chef/cookstyle/pull/38 will fix the rubocop behavior for cookstyle.

stuartpreston commented 7 years ago

Yep. It will be interesting to see what Windows only environments make of this. I'm not sure at the moment where the best place to add any documentation around this would be.

smurawski commented 7 years ago

@stuartpreston might be a good open space topic at Summits..