【发布时间】：2018-01-31 02:17:59
【问题描述】：
我有一个基于 Java 的大型项目，托管在 GitLab 上，它是通过 Jenkins 使用 ant 构建的。 jenkins 机器是一个 windows 盒子，并安装了 SonarQube 扫描仪。作为构建过程的一部分，jenkins 机器会扫描代码，并与单独的 SonarQube 服务器进行通信，该服务器是一个 linux 机器。
目前我们的 git repo 只有基于 windows 的行尾，因为它是从 svn 转换而来的。在此配置下，SonarQube 可以检测代码提交中的新问题，但无法检测新问题的行号。在 GitLab 中，它会在合并请求中附加一般注释，而不是进行常规的内嵌注释。
我使用额外的日志记录运行 SonarQube 分析，发现它在检测到问题的行与代表文件其余部分的行数组之间的字符串比较失败。
特别是，它看起来像是它正在搜索的字符串，在字符串的开头有一个新行，而数组中的字符串在字符串的末尾有一个新行。
凭直觉，我将测试分支中的所有行尾都切换为 unix 风格的行尾，并让 windows 框使用 auto-crlf。这解决了问题，SonarQube 能够匹配字符串，并为它在 GitLab 合并请求中检测到的问题提供了内嵌注释。
由于更改每个文件的每一行以强制 Unix 行结尾比我们想要的更具侵入性，我想知道是否有一些我可能缺少的配置选项可以让 SonarQube 识别 Windows 样式的行结尾，甚至在 linux 机器上运行时？
【问题讨论】：
-
我不确定这里有问题。仅当受问题影响的行是差异的一部分时，GitHub 插件才使用内联 cmets。当您切换行尾时，整个文件将成为差异的一部分，这可以解释所报告的问题。如果您确认受影响的行是差异的一部分，那么请与一些字符串比较分享您提到的额外日志输出。无论如何，我在这里主要是在猜测，因为 GitLab 插件是由社区管理的，而不是由 SonarSource 管理的。
标签： linux git unix sonarqube sonarqube-scan