scripts: ci: check_compliance fails custom projects file that contain DOS line endings

[m-alperen-sener]

The problem:
We have projects files for Bluetooth Launch Studio and PTS application here. Compliance check fails on bls (launch studio project file) files because of line endings which is required by the launch studio, it is not possible to import the file back to launch studio if we change the line endings.

Suggested solution:
Bypass compliance check for bls files.

[henrikbrixandersen]

How is this an issue for the Zephyr Project? Sounds more like an issue for your downstream project/application?

[m-alperen-sener]

More detail:

This file is the project file that we use in Bluetooth Launch Studio to add/delete/update ICS for Zephyr Bluetooth Controller/Host/Mesh qualification. Eventually, this file matters for Zephyr Project because it how we keep track of what is qualifiable with Zephyr.

Bluetooth Launch Studio web app only accepts files with DOS line endings, it seems better to keep the file as it is.

The current compliance check is not possible to pass for this file.

[PavelVPV]

This issue actually prevents this PR to be merged: #68975
Explanation: #68975 (comment), https://discord.com/channels/720317445772017664/1014241011989487716/1217129590401798264

[henrikbrixandersen]

@m-alperen-sener, @PavelVPV Thank you for explaining this.

[Thalley]

This is also an issue for certain Bluetooth configuration files that needs to have DOS line endings to work with testing software

[nashif]

this was fixed in 420ffdd

[Thalley]

this was fixed in 420ffdd

@nashif
Can you elaborate on how reducing the size of the error report helps with DOS line endings? Won't CI still fail?

[nashif]

@nashif
Can you elaborate on how reducing the size of the error report helps with DOS line endings? Won't CI still fail?

CI will fail, of course, but this is not the point or problem. the problem was that CI was getting stuck with 10s of thousands of checkpatch violation and processing them one by one, now we do not do that and fail with showing the errors directly and without trying to inline them on github.

DOS line endings is still a rule violation and we need to fail on it and apply exceptions where applicable.

So I am not sure to be honest what the original enahncement is about? We always have false positives that we override. The commit above was for a similar issue, do not remember which PR it was, there the compliance checks was getting stuck because of the thousands of DOS line endings.

[Thalley]

Thanks. I agree that the compliance not finishing was an issue, but this issue was specifically for DOS line endings, which is still an issue regardless.

I do not consider #77283 a fix for this issue, and we should reopen, as the issue with DOS line ending still exist and ideally we would have some way of disregarding that check for specific files.

[PavelVPV]

The issue still exists: #78400