在 Gradle 构建中禁用 findbugs 检查的错误类别

Disable findbugs checked bug categories in Gradle build

我一直在使用 Eclipse 中的 Findbugs 插件,现在想将该功能移到我的 Gradle 构建脚本中,这样如果检测到任何严重的错误,构建就会失败。我想禁用以下错误类别:

  1. 实验性
  2. 安全
  3. 国际化
  4. 恶意代码

以上是Eclipse插件中的默认设置。然而,在 Gradle 中,查看 documentation I can only find a way to disable individual bug checks. This is however not feasible, looking at the source code,其中有将近 100 个需要单独检查 enable/disable。

是否有更简单的方法来禁用上述类别,以便 Gradle 调用的 Findbugs 的行为与 Eclipse 插件默认配置相同?

编辑: 到目前为止,我们已经发现 "excludeFilter" 选项可用于指定包含应排除的错误检查程序的 XML 文件。然后可以在此文件中指定要排除的类别,如下所示:

<FindBugsFilter>
        <Match>
                <Bug category="EXPERIMENTAL"/>
        </Match> 
</FindBugsFilter>

可以通过在排除文件中指定类别属性来禁用错误类别:

但是这些类别属性似乎没有记录在案,所以我不确定是否找到了所有这些属性。当我发现更多时,将编辑此列表。

我之前没有将 FindBugs 与 gradle 一起使用,但听起来 excludeFilter 选项需要一个 FindBugs XML 文件,您可以使用它来过滤掉整个类别。

The FindBugs Filter manual

For more coarse-grained matching, use code attribute. It takes a comma-separated list of bug abbreviations. For most-coarse grained matching use category attriute, that takes a comma separated list of bug category names: CORRECTNESS, MT_CORRECTNESS, BAD_PRACTICICE, PERFORMANCE, STYLE.

If more than one of the attributes mentioned above are specified on the same element, all bug patterns that match either one of specified pattern names, or abreviations, or categories will be matched.

所以我认为您应该能够制作这样的 XML 文件:

<FindBugsFilter>

  <Match>

    <Bug pattern="EXPERIMENTAL"/>
  </Match>

  <Match>
     <Bug pattern="MALICIOUS_CODE" />
   </Match>
     ...etc
</FindBugsFilter>

你是对的,FindBug 类别列表似乎没有完整记录。 从 https://sourceforge.net/projects/findbugs/files/findbugs/3.0.1/ 搜索源包,您可以在默认 messages.xml.

中找到 BugCategory 定义

我提取了信息并创建了一个过滤器来匹配在 findbugs-3.0 中找到的所有类别。1\etc\messages。xml :

<FindBugsFilter>
    <!-- Probable bug - an apparent coding mistake resulting in code that was 
        probably not what the developer intended. We strive for a low false positive 
        rate. -->
    <Match>
        <Bug category="CORRECTNESS" />
    </Match>

    <!-- Bogus random noise: intended to be useful as a control in data mining 
        experiments, not in finding actual bugs in software. -->
    <Match>
        <Bug category="NOISE" />
    </Match>

    <!-- A use of untrusted input in a way that could create a remotely exploitable 
        security vulnerability. -->
    <Match>
        <Bug category="SECURITY" />
    </Match>

    <!-- Violations of recommended and essential coding practice. Examples include 
        hash code and equals problems, cloneable idiom, dropped exceptions, Serializable 
        problems, and misuse of finalize. We strive to make this analysis accurate, 
        although some groups may not care about some of the bad practices. -->
    <Match>
        <Bug category="BAD_PRACTICE" />
    </Match>

    <!-- code that is confusing, anomalous, or written in a way that leads itself 
        to errors. Examples include dead local stores, switch fall through, unconfirmed 
        casts, and redundant null check of value known to be null. More false positives 
        accepted. In previous versions of FindBugs, this category was known as Style. -->
    <Match>
        <Bug category="STYLE" />
    </Match>

    <!-- code that is not necessarily incorrect but may be inefficient -->
    <Match>
        <Bug category="PERFORMANCE" />
    </Match>

    <!-- code that is vulnerable to attacks from untrusted code -->
    <Match>
        <Bug category="MALICIOUS_CODE" />
    </Match>

    <!-- code flaws having to do with threads, locks, and volatiles -->
    <Match>
        <Bug category="MT_CORRECTNESS" />
    </Match>

    <!-- code flaws having to do with internationalization and locale -->
    <Match>
        <Bug category="I18N" />
    </Match>

    <!-- Experimental and not fully vetted bug patterns -->
    <Match>
        <Bug category="EXPERIMENTAL" />
    </Match>

</FindBugsFilter>