插件发布的自动反馈
简介
新的 Gradle 插件在插件门户发布之前需要经过人工检查才能获得批准。现在，大多数执行的检查都已完全自动化，以减少插件作者的等待时间并降低人为错误的风险。这篇博文介绍了影响社区插件作者的新自动化流程，并解释了这对生态系统的安全性的重要性。
插件发布安全 #
Gradle 的首要任务之一是降低供应链攻击的风险。这种隐蔽的攻击可能具有非常大的规模和影响。例如，一个恶意的社区插件可能会感染大量使用 Gradle 构建的软件系统。您可以在以下博文中阅读更多关于此类攻击和一些示例的信息。
在过去一年中，Gradle 的我们一直在逐步加大力度，以减轻与供应链攻击相关的风险。在插件门户的背景下，我们的主要目标是：
- 更严格地执行插件域名所有权
- 防止插件代码依赖项遮蔽构建的其他“真实”依赖项
当一个新的插件在 Gradle 插件门户上发布时，它会经历一个人工审核过程。这通常只发生在初始版本。Gradle 工程师会检查元数据，并决定是否将其发布到门户或要求对其进行更改。
为了让您更好地了解工程师正在进行的健全性检查的类型，这里有一些示例：
- 插件是否发布到误导性的 GAV（组、工件、版本）坐标？
- 发布用户是否属于拥有该插件的组织？
- 插件是否具有清晰且有用的描述？
- 插件是否具有正确的标签？
- 文档链接是否有效且可访问？
尽管这种方法一直运行良好，但它不必要地增加了向插件作者提供反馈的时间，无论是修复他们可能遇到的问题还是让他们的插件在门户上发布。人工方面也意味着人为错误仍然是可能的。
完全自动化 #
我们已决定将大部分审批检查自动化，作为 插件发布过程的一部分。如果任何检查不成功，发布将失败，并且审批过程甚至不会开始。如果存在任何明显问题，这会立即向插件作者提供反馈，而无需像当前那样花费时间等待人工审核（和拒绝）。
大多数检查都在服务器端运行，因此可以验证的条件集非常广泛。服务器端检查的效果之一是，无论作者使用的是哪个版本的 插件发布插件，都会执行这些检查。
我们理解，最初因自动检查而拒绝发布可能会让人感到有些沮丧，但我们想强调的是，接受插件的标准保持不变。任何现在被自动拒绝的插件，在之前的人工审批过程中也会被拒绝，但会有更长的延迟。通过提供即时反馈，插件作者可以在代码仍然记忆犹新时修复插件审批问题，而不是稍后再次处理。
此外，检查过程尝试提供关于其发现的所有问题的全面消息，而不仅仅是它遇到的第一个问题，因此重试次数应该最少。
我们还在插件发布文档中添加了故障排除指南，以帮助解决最常见的问题。
异常 #
虽然自动化程度很高，但并非所有插件审批检查都适合以这种方式进行。有些事情始终需要人工判断。我们希望，即使这些更改没有消除对人工审批过程的需求，它们也应大大增加无需进一步更改即可获得批准的插件数量。这应该有助于插件作者更快速地成功发布。
还有一点需要注意的是，大多数自动化检查仍然只在插件的初始版本上运行，因此发布插件更新应该像现在一样简单。