Fix: Unset text attribute .travis.yml instead of using eol

[JamesHenry]

No description provided.

[eslintbot]

Thanks for the pull request, @JamesHenry! I took a look to make sure it's ready for merging and found some changes are needed:

• Pull requests with code require an issue to be mentioned at the end of the commit summary, such as (fixes #1234). Please update the commit summary with an issue (file a new issue if one doesn't already exist).

Can you please update the pull request to address these?

(More information can be found in our pull request guide.)

[platinumazure]

Is the issue that *.yml doesn't match .travis.yml due to the leading dot? Or is it specifically that the Travis file needs to be regarded as non-text?

[JamesHenry]

@platinumazure the only known context is here #113.

The gitattributes file was originally added by a windows user, to help windows users.

Originally the file contained just:

 * text=auto
  *.js eol=lf
  *.ts eol=lf

But then whenever I opened the project on my mac, I would get unstaged changes on the .travis.yml file, despite no actual diff/changes.

Adding the *.yml eol=lf was the original way to fix that - but it seems to have had the side-effect of breaking the release job on jenkins... Which I am guessing is on a linux machine @nzakas?

This PR is an attempt to have no issues with local mac development, but also allow the jenkins job to run :)

[platinumazure]

@JamesHenry Okay, I've done some experimenting and I am fairly confident *.yml matches .travis.yml.

I think what's going on is the .travis.yml file in the index has CRLF line endings, despite the gitattributes policy specified for *.yml files. As is noted in the gitattributes docs, adding the attribute to gitattributes does not retroactively apply to files that were committed with the wrong LF pattern before the attribute was added. So I guess the PR I would rather see is the result of these operations:

1. Revert the .gitattributes change (so that *.yml eol=lf is the last line again)
1. Run rm .travis.yml
1. Run git reset
1. Run git add -u

EDIT: These instructions are better: https://help.github.com/articles/dealing-with-line-endings/

Hopefully this means that the file will be re-committed with LF line endings.

[ilyavolodin]

@JamesHenry This wouldn't be the fix, since our release script is ran on Jenkins server, not Travis. So it's very unlikely this change will affect anything.

[JamesHenry]

@ilyavolodin do you agree with @platinumazure's proposal?

[JamesHenry]

I still don't understand why this is an issue on Jenkins, but not on Travis or locally...

[JamesHenry]

But @platinumazure suggestion seems reasonable to me :)

[ilyavolodin]

@JamesHenry Sorry, I think I misunderstood the core issue. I think it's worth a try at least. I can merge this in, and try running a release.

[platinumazure]

As noted on the chat, I'm okay with merging this in as is just to try to unblock the release. I still hope someone will try my suggestion here at some point in the future. 😄

[ilyavolodin]

@nzakas I'm not going to run this release, since this includes a breaking change, and release script will automatically release this as v1.0.0. I'm leaving it up to you to decide if this is ready to be 1.0 release.

[JamesHenry]

+1, as agreed on chat, we want to make sure we are all on the same page as to what release this will be

[platinumazure]

Approved, contingent on my comments about what is probably the right way to fix this in the long-term. 😄

[nzakas]

The release will be 1.0.0, that's fine. I think the project is probably solid enough to use with a few caveats.

@JamesHenry I'll leave it up to you which path to take to fix this, and then whoever is around can trigger the release.

Please be sure to update the commit message to include the issue (#113).

[JamesHenry]

Thanks, @nzakas!

In which case, I will close this and submit a PR implementing @platinumazure's proposal.