把C/C++test接进GitLab，难点通常不在工具能不能跑起来，而在结果要不要真正拦住合并。Parasoft官方给出的GitLab集成思路很明确，核心是让流水线里先完成代码分析，再生成GitLab可识别的SAST报告并作为制品上传；GitLab这边再用流水线状态或安全审批策略决定合并能不能继续。Parasoft还专门提供了`cpptest-gitlab`示例仓库，里面把CMake、Make和GitLab SAST报告的接法都给出来了。

　　一、C/C++test GitLab CI集成怎么做

　　这件事最稳的落地方式，不是先想着怎么做门禁，而是先把分析输入、Runner环境和报告上传三步接顺。前面接对了，后面的门禁其实只是加规则，不需要返工整条流水线。

　　1、先把分析输入准备好

　　如果项目是CMake，Parasoft的示例做法是先在构建阶段生成`compile_commands.json`，再把这个文件作为制品传给分析阶段；如果项目是Make，示例做法是用`cpptesttrace`包住原始构建命令，生成`cpptestscan.bdf`，后面的分析作业直接拿这个输入文件跑。也就是说，GitLab CI里最先要定的，不是门禁规则，而是你到底走`compile_commands.json`还是`.bdf`这条线。

　　2、Runner上要把环境一次配全

　　Parasoft的GitLab示例明确要求Runner上能直接调用编译工具链和C/C++test，路径里要能找到`cpptestcli`，Make路线还要能找到`cpptesttrace`。如果是Windows Runner，Parasoft还特别提醒过PowerShell版本和文件编码问题，所以这一步最好在正式接项目之前就先单独验证。

　　3、分析作业里要生成GitLab能识别的报告

　　Parasoft给GitLab的标准接法，是在报告配置里加入`report.format=xml,html,sast-gitlab`，然后通过`cpptestcli`跑分析。示例里还会把Git仓库地址、工作目录和分支信息一起写进报告配置，这样GitLab展示结果时，代码定位和分支关联会更完整。

　　4、把`report.sast`作为SAST制品上传

　　GitLab要在流水线安全页和合并请求里识别扫描结果，不是看普通附件，而是看`artifacts:reports:sast`这一类制品。Parasoft的示例直接把`reports/report.sast`上传到这个位置，同时把XML、HTML这些报告作为普通制品一并留档，这样既能给GitLab看，也方便团队自己回查。

　　5、想让流水线直接拦住提交，就让分析作业失败

　　如果你要的是最直接的硬门禁，C/C++test这边可以用`-fail`开关。Parasoft文档说明得很清楚，启用这个开关后，只要出现静态分析违规，`cpptestcli`就会带着对应退出码结束；GitLab这边只要把这个分析作业设为正常失败即失败，就能把流水线状态直接拉成failed。

　　二、C/C++test合并请求门禁怎么接

　　合并请求门禁常见有两种接法，一种是靠流水线成败硬拦，另一种是把Parasoft结果当成GitLab的SAST扫描结果，再交给合并请求审批策略处理。前者更简单，后者更像正式的安全门禁。

　　1、先把Merge Request Pipeline跑起来

　　GitLab官方要求很明确，想让作业在合并请求场景里执行，`.gitlab-ci.yml`里必须直接写`rules`或`workflow:rules`，并匹配`CI_PIPELINE_SOURCE=="merge_request_event"`。如果这里没配好，后面就算上传了SAST报告，也只是普通分支流水线结果，门禁不会落到合并请求本身。

　　2、基础门禁就用`-fail`加`Pipelines must succeed`

　　这条线最省事。C/C++test负责在发现违规时让分析作业失败，GitLab项目设置里再打开`Pipelines must succeed`，这样只要合并请求对应的流水线没过，GitLab就会直接拦住合并。GitLab文档还特别说明了，当项目同时有分支流水线和合并请求流水线时，开启这个选项后会优先检查合并请求流水线。

　　3、想做基于新问题的门禁，就接SAST审批策略

　　Parasoft的GitLab示例已经说明，C/C++test结果可以作为SAST漏洞显示在GitLab里。GitLab官方文档则说明，SAST结果在合并请求里会显示新增和已解决的问题；再往上一步，就可以在`Security&Compliance`下面创建`Scan result policy`，用`IF SAST`这类条件对新发现的问题加审批要求。这个方案的好处是，不一定要让流水线整体失败，也能单独把新增安全问题卡住。

　　4、默认分支一定要先有基线结果

　　GitLab的安全审批策略不是只看当前分支，它需要拿源分支和目标分支的扫描结果做比较。官方文档反复强调，源分支和目标分支都要有成功完成并产出安全报告的流水线，否则策略无法可靠评估，合并请求就可能被额外要求审批，甚至直接卡住。所以真正上线前，先在默认分支把C/C++test流水线跑通一次，这一步别省。

　　5、Fork合并请求要提前想好谁来跑

　　GitLab对fork的处理和同仓库分支不一样。官方文档说明，来自fork的合并请求默认在fork项目里跑流水线，使用的也是fork那边的CI配置和变量；如果要在父项目里跑，需要有权限的成员手动触发，而且GitLab会给出风险提醒。对带许可证和私有Runner的C/C++test任务来说，这一步最好提前定清楚。

　　三、C/C++test接门禁前先统一哪些口径

　　很多团队不是不会接GitLab，而是流水线接上以后，今天拦全部问题，明天只拦新问题，后天又把安全结果和普通编码规范混着卡，最后开发根本不知道什么情况下会被挡住。真正要长期跑稳，门禁前最好先把口径统一。

　　1、先定你拦的是全部违规还是指定配置

　　Parasoft示例里默认用的是`builtin://Recommended Rules`，这适合先把链路打通；但正式上线时，通常要换成你们自己的测试配置，否则门禁范围会忽大忽小。换句话说，先定测试配置，再谈门禁强度，比先把GitLab开关全打开更重要。

　　2、再定你是只看GitLab，还是同时发到DTP

　　如果团队后面还要做趋势、基线、项目级汇总，Parasoft CLI本身支持`-publish`把结果送到DTP，相关连接参数也可以放进`localsettings`。这不是GitLab门禁的必选项，但如果项目多、分支多，只靠GitLab页面看结果，后期会比较碎。

　　3、最后确认报告格式和版本别掉链子

　　Parasoft官方示例已经提醒，新的GitLab版本可能要求SAST v15报告，而C/C++test从2023.1.1开始默认生成SAST v15。也就是说，如果你现在还在用更早版本的C/C++test，最好先确认报告格式兼容性，不然流水线能跑完，GitLab那边却不一定按预期展示。

　　总结

　　C/C++test接GitLab CI，最实用的顺序就是先把分析输入和报告上传跑通，再决定门禁走哪条线。要简单、直接、容易落地，就用`cpptestcli`的失败退出加上GitLab的`Pipelines must succeed`；要更像正式安全流程，就把C/C++test结果作为SAST报告上传，再用GitLab的合并请求审批策略去卡新增问题。真正决定效果的，不只是工具有没有接上，而是默认分支基线、测试配置范围和门禁口径有没有先定清楚。