使用 Gradle、Jenkins 和 Sonar 实现 CI/CD 流

Question

因此，我目前正在尝试为我的一个项目实施 CI/CD 工作流程，该项目将向公众发布。因为我发布的更多的是一个框架，所以我承认人们会接受我的代码，按照他们认为合适的方式更改它，并自己托管他们的更改（如果他们愿意的话）。所以我不想在他们的构建过程中强加任何额外（即检查样式规则、不必要的依赖等）。

所以我（个人）选择编写框架的路径是使用 Gradle 进行构建，并在提交时启动 Jenkins 构建，它将运行所有单元测试，执行静态分析，然后打包必要的文件转换成人们可以下载的格式。

1. 编写代码
2. 运行本地单元测试
3. 提交代码
4. 启动 Jenkins 构建
5. 运行单元测试
6. 运行集成测试
7. 对结果进行分析
8. 将分析上传到 SonarQube 服务器
9. 将构建文件和打包成二进制和源代码版本。

然而，我的问题是我无法在 Jenkins 中配置它的所有声纳方面。正如我所说，我不想将我的规则强加于其他人的流程，因此我将功能分离为 Jenkins 步骤。但是，如果我执行 Sonar 步骤，它将完全排除单元测试方面。我无法确定原因。但是，如果我修改 Gradle 文件以包含

apply plugin: 'sonar-runner'

并添加一个Invoke Gradle Task 步骤而不是声纳任务，它工作正常。

我是不是走错了路？如果我在 Gradle 文件中包含该部分，我会从中得到我需要的东西，但我将 Gradle 要求强加给下载我的代码的人（可能使用 Maven 代替）。有没有办法解决这个问题？

Answer 1

通过在 Gradle 构建脚本中包含声纳插件，您不会“强加”任何东西。开发人员不需要运行声纳任务来构建您的项目，只要配置声纳所需的任何必要配置在丢失时不会破坏构建，我会说你很高兴。

开源项目构建包含特定于发布或部署的逻辑的情况并不少见。这很好，只要 a) 在指定 CI 环境之外运行这些任务失败（通常是由于没有上传到发布 repo 的权限）并且 b) 开发人员仍然可以构建/测试而无需运行这些任务。

总的来说，我认为您的后一种方法更好，因为您现在对特定 CI 基础架构的依赖减少了，这将使迁移更容易。