在我看来，在项目本身内部定义项目的所有与构建相关的配置或与质量相关的规则(作为人类可读的配置文件)是一个很好的做法。这样做有几个优点:任何参与该项目的开发人员都可以轻松看到它使用的配置；人类可读的配置文件是复制配置的自动记录方式(例如，在需要安装新服务器或切换到不同服务的情况下)；配置历史记录与项目的其他历史记录存储在同一位置。
但是 AFAIU SonarQube 的文档更倾向于使用 SonarQube UI 来更改项目的设置。例如，我找不到如何使用属性文件配置与默认值不同的质量门，而是建议使用 UI 或使用 curl 来配置它。 。在我看来，这会让外国开发者无法明显看出该项目使用了不同的质量门。
- 我是否错过了什么？文档实际上是否在某处解释了如何在配置文件中配置项目的 SonarQube 设置？
- 如果不是，SonarQube 开发人员是否确实认为我所描述的良好实践实际上并不是一个良好实践，为什么？
- 是否有一些(可能未记录的)功能可以实现我想做的事情？
最佳答案
您没有遗漏任何内容，实际上某些配置(例如质量门和质量配置文件)只能通过服务器 UI 进行配置。主要是因为通常，您希望在组织和不同项目之间共享此配置，因此更容易将其集中在服务器本身上。
可以通过创建 sonar-project.properties 文件或在 maven 或 gradle 构建文件中设置属性来设置项目特定设置。您可以通过这种方式配置排除、覆盖范围、测试报告。
您可以使用 Web api 以编程方式配置服务器，但对每个项目都这样做并不是预期的使用模式，您可能会遇到一些困难。
关于sonarqube - 通过属性文件进行独立的 Sonar 配置，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/53021167/