Parasoft接入Jenkins怎么配置 Parasoft Jenkins构建失败日志怎么排查

Parasoft接入Jenkins应当怎样配置，以及Jenkins构建失败时日志又该如何排查，这两个问题，是不少团队在把静态分析、单元测试和覆盖率接入CI的时候，都会碰到的。这里需要先分清楚两件事情，Parasoft这个工具，它负责的是执行分析、生成报告；而Jenkins这边，它负责的是调度任务、展示结果，还有控制流水线的状态。如果前一个环节没有生成出有效的报告，那么后面插件的配置就算再完整，Jenkins的页面上，也不会有正常的结果出来。所以在进行配置的时候，不能只盯着插件那边的界面，而是要把工具的执行、报告的输出、路径的读取，还有质量的判断标准，这几样东西连在一起去看。

一、Parasoft接入Jenkins怎么配置

在把Parasoft接入Jenkins的时候，最好是先在本地，或者在构建节点上面，确认一下这个工具，它是能够独立运行的，然后再把它放进流水线里面去。有不少失败的情况，原因并不在Jenkins本身，而是许可证、工程的路径、编译的环境，或者命令的参数，在CI节点上，没有提前准备好。

1、准备好构建节点的环境

需要先确认一下，在Jenkins的节点上面，对应的Parasoft工具已经安装好了，并且许可证、工程所依赖的东西、编译器的环境，还有那些必要的环境变量，也都配置好了。这一步，需要和开发用的机器区分开来看，在开发机上能够跑起来，并不代表Jenkins的节点，也一定能跑起来。特别是对于C和C++的项目，编译器的路径、构建的脚本、include的目录、宏定义，还有工作的目录，这当中的任何一项，如果不一致，都有可能会导致分析失败。

2、把扫描或者测试的命令配置好

在Jenkins的任务里面，加入Parasoft分析的命令，先完成编译、静态分析、单元测试，或者覆盖率的采集，然后再去输出XML、HTML这一类格式的报告文件。编写的命令里面，要明确地指定好工程的路径、规则集、报告的目录，还有执行时候的配置，不要依赖那些临时的路径，或者个人电脑上面的默认配置。

3、把Parasoft的报告发布出来

在构建后操作的设置里面，配置好Parasoft报告文件的路径，让Jenkins能够去读取分析的结果，并且生成趋势图、发现项的列表，还有覆盖率的展示。配置报告路径的时候，需要以当前workspace的路径为准。多模块的项目、Docker的环境，还有远程的节点，这几类情况，是最容易出现路径错位的，可以先把报告的目录打印在构建日志里面，确认文件已经生成出来了，然后再去配置发布的步骤。

二、Parasoft Jenkins构建失败日志怎么排查

构建失败的时候，不应该只看最后的那一行红字。Parasoft接入Jenkins以后，失败的情况，有可能发生在拉取代码、编译、工具启动、许可证校验、报告生成、报告发布，或者门禁判断，这好几个环节。排查的时候，需要先把失败的阶段给找出来。

1、先查看控制台输出的内容

打开构建的控制台输出以后，按照流水线的阶段去查看日志，确认一下失败的情况，是发生在构建之前、分析的过程当中，还是在报告发布以后。如果Parasoft的命令，它根本就没有真正启动起来，那问题多半是出在Jenkins的脚本，或者环境的变量上面；如果命令启动以后，又中断了，那就要去看工具本身的报错信息；如果说，分析是完成了，但是Jenkins页面上却没有结果，那就要重点去检查报告存放的路径，还有文件的格式。

2、检查一下许可证和工具路径方面的问题

日志里面，如果出现了license、server、not found、invalid option这一类的提示信息，那就要优先去检查许可证的服务器、工具的安装目录、命令的参数，还有执行的权限。Jenkins服务所使用的账号，可能和本地登录的账号是不一样的，它能不能访问到许可证、工程的目录，还有工具的目录，这几样，都需要单独去确认。

3、核对一下报告，是不是真的生成出来了

如果构建结果显示是成功的，但是Parasoft这一块的结果却是空的，那就要去检查一下报告文件，是不是真的生成出来了，文件的名字和发布配置里写的，是不是一致的，路径的通配符有没有写错。有些项目，它把报告生成在了子模块的目录里面，但是Jenkins发布这个步骤，却是在根目录下面去找文件，这样一来，结果就会显示为空。

三、Parasoft接入Jenkins后怎么保持稳定

成功接入进去，还只是第一步而已，到了后面，更加重要的事情，是怎么让这个结果是稳定的，可以重复出现的。不然的话，今天还能正常出报告，明天换了一个节点，或者改动了规则集，再或者清理了一下workspace，构建就又会失败。CI这一块的配置，要尽可能地固定下来，避免去依靠个人的经验，临时去维护。

1、把扫描的配置固定下来

可以把扫描的配置记录下来，写清楚工具是哪个版本、规则集是哪一套、许可证的地址是什么、跑在哪一个Jenkins节点上、报告放在哪个目录里面，还有排除掉的范围，是哪些。这样做，等到后面告警的数量发生变化的时候，团队就能判断出来，这到底是因为代码本身发生了变化，还是因为扫描的配置发生了改变。如果连配置的记录都没有，排查起问题来，就会非常被动。

2、把脚本的失败和门禁的失败区分清楚

Parasoft在扫描发现了严重的问题以后，Jenkins可能会被标记成失败，或者是不稳定的状态。这种情况，和命令执行时候的异常，并不是同一回事。前面那一种，说明是质量的判断标准被触发了，需要去处理代码的问题、测试没通过的情况，或者覆盖率不够的地方；后面那一种，则说明是环境、命令，或者报告的流程有问题，需要先去把CI的配置给修好。

3、把构建的证据保留下来

每一次构建，最好是能把XML的报告、HTML的报告、控制台的日志，还有那些关键的配置文件，都归档保存下来。这么做的话，构建失败以后，就不需要只靠着Jenkins页面上，那几句简短的提示去判断问题了，而且，也方便去对比不同版本的扫描结果，和质量变化的趋势。

总结

Parasoft接入Jenkins要怎么去配置，以及Jenkins构建失败的时候，日志要怎么去排查，这里面关键的地方，是把流程拆开来看清楚。先要让Parasoft这个工具，在Jenkins的节点上，能够稳定地跑起来，然后再让它生成固定格式、固定路径的报告，最后，才由Jenkins去发布结果，并且执行质量的判断。在排查失败的原因时，应当按照构建的阶段、工具的命令、许可证、报告的路径，还有门禁的状态，逐项去进行确认。这样做，Parasoft接入Jenkins这件事，才真正能够为持续集成和质量的评审提供服务，而不只是给流水线里面，多增加了一个不太稳定的环节。