Line endings change breaks all tests

[GeertvanHorrik]

This change broke all my verification tests.

Although it might be a very valid change, it breaks tests that were (at least seem to be) working fine.

I use Beyond Compare (on Windows) to update the files, and these (somehow) always end op in Windows line endings (even though settings are set to respect the source line endings). I can change the file line endings manually, but that is very cumbersome.

Is there a way to globally disable this setting in Verify or work around this issue (without reverting back to an older version, since that would lock me out of other feature / bug fixes) or automate this over 100+ repositories?

In other words: I am looking for a workflow (with Beyond Compare) that would keep Verify happy with the line endings, etc.

[SimonCropp]

sorry @GeertvanHorrik i may have stuffed up on that one

let me take a look when i get back to my computer

[SimonCropp]

what do you have in your .gitattributes and .editorconfig?
https://github.com/VerifyTests/Verify#text-file-settings
https://github.com/VerifyTests/Verify#editorconfig-settings

[GeertvanHorrik]

That's it. I updated the .gitattributes, but also had to reset the repository cache on the build agents to respect this new setting. It looks like the tests are now succeeding without having to change anything (except the .gitattributes, which is easy via repository sync). Thank you very much for your investigation and replies.

[SimonCropp]

good to hear

[noqn]

@SimonCropp
Just a heads up, the VS Code diff editor doesn't respect end_of_line in .editorconfig

The new behavior goes something like:

1. Run new/cleaned test.
2. New empty .verify.txt file is created.
3. VS Code diff editor opens.
4. Tester reverts the .received.txt -> .verified.txt diff
5. .verify.txt now has crlf eol (regardless whether the .received.txt file had lf).
6. Test is run again, Verify now throws an exception.

So while we could commit the files straight away (converting eol to lf) and the tests would pass in pipelines, our manual workflow is now completely broken.

(Just to have it mentioned, doing any git add commands in the middle of the manual workflow to convert to lf would be a major inconvenience, so I don't see that as a solution either. )

VS Code diff editor is something that everyone in my team is using and I don't see people changing from, fyi.
(I also suspect many other editors behave like this too.)

We've frozen to v31.20.0 for now.

I'm guessing there are plenty others in our shoes, and that it would most likely prevent a lot of headache if the new eol behavior was reverted.

Best wishes

[SimonCropp]

@noqn can u share a minimal repro. as a github repository

[SimonCropp]

do you have https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig installed?

[SimonCropp]

also what process are u using to accept the change once it shows in VSCode? eg diffengine tray? or something else?

[noqn]

I just entered vacation, so sorry if I'm brief.

You can reproduce it in a repo conformant to the Verify .editorconfig and .gitattributes standards and is passing VerifyChecks.Run().

do you have https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig installed?

Thanks for trying to help, but for us the path of least resistance for several reasons is to either freeze Verify or fork it internally.
(So just to be transparent, I'm writing to give feedback rather than to ask for support.)

I think adding an extension as an official requirement to the library is far from optimal, it quite ruins out-of-the-box experience among other things.

Besides, users are likely to run into this with other editors too. I really think this is going to add a lot of headache that can be prevented.

What are your thoughts?

[noqn]

If you want my two cents, from a library perspective I'm thinking this behavior should be opt-in, at most.

Regardless, thanks for taking your time on this, it's greatly appreciated.