GitLab CI中SAST产物在后续流水线阶段被删除的排查求助

以下是针对你的配置和问题的具体排查步骤：

• 确认SAST job确实生成了目标文件
  前往sast job的执行日志，检查扫描完成后是否有gl-sast-report.json的生成记录。可以在sast job的script末尾添加命令，强制验证文件存在：

  sast:
    stage: test
    script:
      - # 保留模板原有脚本
      - find . -name "gl-sast-report.json" -type f
      - ls -la ./gl-sast-report.json
    artifacts:
      paths:
        - gl-sast-report.json
      expire_in: 1 week
  

  如果日志显示文件不存在，说明SAST扫描本身未生成报告，需要先排查扫描器的配置问题。

• 检查SAST模板与自定义配置的冲突
  你引入的Security/SAST.gitlab-ci.yml模板中，sast job可能已经自带了artifacts配置。直接覆盖artifacts字段可能导致模板中的路径被忽略，或者你指定的路径与实际生成路径不符。可以尝试改为追加路径而非覆盖：

  sast:
    stage: test
    artifacts:
      paths:
        - gl-sast-report.json
      expire_in: 1 week
    extends: sast # 继承模板的基础配置，避免覆盖关键逻辑
  

  另外，部分SAST扫描器会将报告生成在子目录（如tmp/），需要确认实际路径后在paths中填写正确值。

• 验证dependencies配置的有效性
  确保：

  1. sast job在当前流水线中成功执行（失败的job不会传递artifacts）；
  2. report_creation的dependencies字段仅指定sast，没有其他冲突的依赖配置；
  3. 在report_creation的script开头添加命令，查看工作目录内容：

     pwd
     ls -la
     find . -name "gl-sast-report.json"
     

     确认artifacts是否被正确解压到工作目录。

• 排查自定义镜像的工作目录问题
  你使用的gl-sast-parser镜像可能修改了默认工作目录（GitLab CI默认工作目录为/builds/<namespace>/<project>）。如果镜像的WORKDIR设置为其他路径，artifacts会被解压到GitLab默认目录，但你的脚本会在镜像指定的目录执行，导致找不到文件。可以在report_creation的script中切换到GitLab工作目录：

  report_creation:
    stage: report
    image: gl-sast-parser
    script:
      - cd /builds/$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME
      - find . -name "gl-sast-report.json"
      - # 后续解析脚本
    dependencies:
      - sast
    artifacts:
      paths:
        - gl-sast-report.html
  

• 检查artifacts过期时间的影响
  虽然你设置了expire_in: 1 week，但如果report_creation job是在sast job执行一周后才运行（比如手动触发后续阶段），artifacts可能已被清理。确保两个job在同一个流水线中连续执行，或延长过期时间。

内容的提问来源于stack exchange，提问作者derdon