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