Gradle@3流水线失败，如何标记为成功以集成SonarQube？

一、如何将流水线始终标记为成功 #

方案1：流水线层面强制覆盖结果 #

在你的Gradle任务之后添加一个脚本任务，不管前面任务执行结果如何，强制将流水线标记为成功。以Azure Pipelines为例：

- task: Gradle@3
  name: GradleBuild
  timeoutInMinutes: 0
  continueOnError: true
  inputs:
    gradleWrapperFile: '$(Build.Repository.LocalPath)/gradlew'
    workingDirectory: '$(Build.Repository.LocalPath)'
    tasks: 'build --continue'
    publishJUnitResults: true
    testResultsFiles: '**/TEST-*.xml'
    javaHomeOption: 'JDKVersion'
    jdkVersionOption: '1.17'
    gradleOptions: '-Xmx3072m'
    sonarQubeRunAnalysis: false
    spotBugsAnalysis: false

- script: echo "##vso[task.complete result=Succeeded;]"
  condition: always()

最后这个脚本会无视前面所有任务的状态，直接将流水线标记为成功。

方案2：修改Gradle命令退出码 #

在Gradle命令后追加强制返回0的逻辑，比如用Bash执行：

- task: Bash@3
  inputs:
    targetType: 'inline'
    script: |
      ./gradlew build --continue
      exit 0

这种方式会让Gradle执行完所有能执行的任务后，强制返回成功退出码。

二、这种做法是否合理？ #

完全不合理。流水线失败是明确的告警，你的项目存在多个严重问题：

• 单元测试失败：业务逻辑不符合预期，存在功能缺陷
• Lint分析报错：包括工具bug或代码规范问题，影响代码可维护性甚至运行稳定性
• Android包名不合法：直接导致编译产物无效，无法正常打包发布
• 数据库迁移验证失败：新旧数据库结构不一致，上线后可能引发数据异常
• OOM和R8混淆失败：构建环境或配置存在问题，无法生成可用的编译产物

强行掩盖失败，等于放弃CI/CD的核心价值——提前发现问题、阻止有缺陷的代码流入后续环节。

三、对SonarQube集成的影响 #

1. 分析数据缺失：SonarQube需要的测试覆盖率、编译代码信息等数据，可能因任务失败未生成，导致分析结果缺少关键指标，无法反映项目真实质量。
2. 质量门禁失效：如果SonarQube配置了质量门禁（比如要求测试通过率、代码异味阈值），提交虚假的成功流水线数据会让门禁彻底失去作用，无法拦截有问题的代码。
3. 排查难度增加：线上出现问题时，无法通过SonarQube的历史分析记录回溯对应构建状态，因为构建结果被人为篡改，掩盖了当时的问题。

四、更合理的解决方案 #

1. 优先修复关键失败任务 #

从失败日志看，按优先级处理：

• 修复tests:uitests:verifyReleaseResources的包名问题：将ui改为合法的Android包名（如com.yourcompany.ui）
• 解决数据库迁移验证失败：调整SQLDelight迁移脚本，确保needsVerification字段默认值在新旧结构中一致
• 处理OOM问题：增大Gradle内存配置，比如将gradleOptions改为-Xmx4096m
• 修复Lint分析bug：更新Lint相关依赖，或临时禁用出错模块的对应Lint规则
• 修复单元测试失败：根据测试报告修改测试用例或业务逻辑

2. 拆分流水线任务 #

将构建、测试、SonarQube分析拆分为独立阶段，仅让SonarQube依赖关键成功任务：

• 先执行单元测试、Lint检查等关键任务，失败时直接终止流水线
• 关键任务成功后，再执行SonarQube分析
• 对非核心任务（如特定环境的混淆），可设置continueOnError: true，但关键任务必须保证成功

3. 临时应急方案（不推荐长期使用） #

如果需要临时完成SonarQube集成，可修改Gradle任务，仅执行SonarQube必需的环节，跳过失败任务：

tasks: 'compileDebugSources testDebugUnitTest sonarqube'

这只是权宜之计，最终仍需修复所有失败任务。

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