1. 产品简介
  2. 快速开始
  3. 编写构建流程
  4. 配置构建计划
  5. 构建环境依赖包
  6. 构建制品
  7. 构建节点
  8. 管理构建计划
  9. 系统插件
  10. 自定义团队插件
  11. 最佳实践
  12. 常见问题
  13. 词汇表
代码扫描 / 常见问题

常见问题

扫描任务执行失败怎么办?

扫描任务的执行环境基于持续集成,因此若任务执行失败可能与构建节点的计算资源有关:

  • 使用团队内默认构建节点

    标准版团队的构建并发数量限额为 1 个,在执行扫描任务时团队内存在其他构建任务,故失败。

  • 接入自定义构建节点

    扫描任务的目标代码量较多,并且启用了诸如 SQJava、Eslint 等资源消耗较多的工具,而执行构建任务的自定义构建节点配置较低,导致扫描任务执行时机器内存不足,构建任务执行超时后中断。

解决方案:

  1. 在扫描方案中过滤无需扫描的组件代码路径,比如 .*/third_lib/.*.*/vendors/.* 等。

  2. 在扫描方案中停用部分暂不使用的扫描规则。

  3. 升级构建节点的资源配置。

  4. 根据日志进行问题定位。

    你可以在「扫描历史」→「扫描日志」→「工具日志」中下载执行日志,其中通常会包含具体编译失败的信息。

编译失败如何处理?

若扫描任务提示编译失败,这可能是因为扫描任务中涉及到了编译过程。当扫描方案中启用了扫描规则时,例如使用了 SQJava、Spotbugs、InferJava 这三款工具,那么需要前往「扫描方案」→「编译配置」中正确填写当前项目的编译环境以及编译命令。

若不需要使用到上述工具,请前往「扫描方案」→「查看已启用的规则」,在搜索框中输入规则名称后进行移除。

若需要保留上述工具规则,你可以通过以下流程进行问题定位:

  1. 前往「扫描任务」→「扫描历史」中找到本次编译失败的执行记录,点击执行概况。查看本次失败所涉及的工具,并下载此工具的执行日志。

  2. 自下而上浏览工具的执行日志,定位构建失败的详细原因。

  3. 根据构建失败的原因,前往「扫描方案」→「编译配置」中调整编译环境及编译命令。

编译过程中需要登录制品仓库怎么办?

  • Maven 仓库

    在本地的 settings.xml 文件中配置 username 和 password 后,将文件上传至需要被扫描的代码仓库中,在编译命令中指定使用该配置文件。例如填写 mvn compile -s ./settings.xml 命令,编译命令会在构建节点中检出代码后的根目录执行。

  • Gradle 仓库

    若通过 Gradle 工具进行打包与构建,那么可以在 build.gradle 中设置 username 和 password。

编译过程需要与其他服务器进行通讯怎么办?

需保证目标服务器具备公网访问能力。在「构建计划」→「基础信息」中获取构建节点的出口 IP,在目标服务器中的白名单中添加构建节点的出口 IP。

或直接将目标服务器接入至自定义节点中,直接使用目标服务器执行扫描任务,在构建任务中的流程配置中写入依赖调用命令。

扫描时间过久如何解决?

扫描任务的执行时间主要受两个维度影响:代码量和启用规则量。SQ、SQJava、Spotbugs、inferJava 这几款工具是相对执行耗时较久的工具,若您代码量相对较大,则有可能出现超时现象。

以下是常见处理执行过久的方案:

  1. 减少不需要的规则。在扫描方案中适当屏蔽不需要的规则,按照工具维度屏蔽规则。前往「扫描方案」->「扫描规则」→「查看已启用的规则」,输入规则名称后进行移除。

  1. 屏蔽无需扫描的代码。前往「扫描方案」->「过滤配置」添加目录或文件过滤。

  1. 拉取依赖超时。若您的方案中有编译型工具,且部分依赖存放在其他服务器中,请注意编译命令中是否指定了托管在其他服务器上的 setting 文件,以及是否允许持续集成访问其他服务器,避免因拉取依赖太久导致执行超时。

提示文件嵌套过深怎么办?

使用 eslint、Lizard、styleLint 工具时提醒文件嵌套深度过深。通常文件嵌套过深现象出现在依赖包中,例如 node_moudle,请在扫描方案中过滤第三方依赖文件。

如何屏蔽扫描规则?

若部分规则存在发现问题价值低、误报率高等问题,而不希望继续使用该规则进行扫描,可以在问题列表中选取低价值问题,直接屏蔽对应规则。

在问题详情中也可以通过查看问题详细信息及规则信息判断是否需要屏蔽此规则。

你也可以前往「扫描方案」→「查看已启用的规则」屏蔽扫描方案中的部分规则。

为什么责任人有时是“灰的”?

问题列表中的责任人默认为问题代码的最初提交人。扫描任务通过读取 Git 中提交者邮箱,比对团队成员的 CODING 账号邮箱进而判定谁是责任人。由于团队成员在本地配置的邮箱信息可能与 CODING 账号中的邮箱信息不匹配,将出现如下未匹配到责任人的效果:

将 Git 提交者信息与账号邮箱对应起来即可修改此问题。

如何导入本地扫描工具?

请参考阅读《集成外部扫描工具》

若使用 checkstyle 工具,则支持导入工具的配置文件,比如 checkstyle-checks.xml。点击「扫描方案」→「扫描规则」的 ··· 按钮导入规则配置。

如何定制扫描规则?

前往「扫描方案」→「查看已启用的规则」,点击目标规则的「编辑」按钮,你可以根据情况调整规则的严重级别。建议在对工具有一定了解的情况下,参照已有规则参数进行定制。

并非每项规则都支持定制规则参数。

为什么暴露的问题结果数量较本地工具更少?

针对扫描问题做了聚合算法。例如在同一个源码文件 & 同一个规则 & 错误原因相同的代码会归并为一个问题。考虑到文件相同、规则相同、错误原因相同的问题,开发人员可以在一起批量解决,所以聚合在一起能够降低开发同学的查看成本与修复时的心理负担。

圈复杂度超标如何解决?

建议采用重构函数的方式,即提炼函数、替换算法。简化条件表达式的方法有逆向表达、分解条件、合并条件以及多态取代条件式等。简化函数调用可以通过采取读写分离、参数化和以明确函数取代参数的方法进行实现。

如何扫描外部仓库?

若想要使用代码扫描工具扫描托管在 Github 或其他第三方开源代码仓库,需通过持续集成执行代码扫描任务。

  1. 参考此文档关联外部仓库。

  1. 创建持续集成任务,选择自定义构建过程模板,代码来源选择已关联仓库。

  1. 添加代码扫描阶段,手动选择扫描方案。

保存后点击立即构建按钮即可触发外部仓库代码扫描任务。

上一篇自动匹配语言
最近更新
感谢反馈有用
感谢反馈没用

在阅读中是否遇到以下问题?

您希望我们如何改进?

工单咨询