# Automatic Feedback on Plugin Publication

DevFeed: [Automatic Feedback on Plugin Publication](<https://devfeed.tech/articles/automatic-feedback-on-plugin-publication-24679.md>)

Original publisher: [Read original article](<https://blog.gradle.org/plugin-portal-validations>)

Author: Jozsef Bartok

Published: 2021-11-04T04:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Security](<https://devfeed.tech/topics/security.md>), [Automation](<https://devfeed.tech/topics/automation.md>), [Publishing](<https://devfeed.tech/topics/publishing.md>)

Tags: [automation](<https://devfeed.tech/tags/automation.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [gradle-plugin](<https://devfeed.tech/tags/gradle-plugin.md>), [publication](<https://devfeed.tech/tags/publication.md>), [security](<https://devfeed.tech/tags/security.md>), [supply-chain-attacks](<https://devfeed.tech/tags/supply-chain-attacks.md>)

## AI overview

Gradle has automated most Plugin Portal approval checks for new plugins. The change aims to provide faster feedback, reduce human errors, and improve ecosystem security by enforcing domain ownership and preventing dependency shadowing.

## Source excerpt

New Gradle plugins undergo a manual inspection before they get approved to be published in the Plugin Portal. Most of the performed checks are now fully automated in order to reduce wait time for plugin authors and reduce the risk of human errors. This blog post describes the new automation affecting community plugin authors and explains that it is important for the security of the ecosystem. Plugin Publishing Security One of our priorities at Gradle is reducing the risk of supply chain attacks. Such insidious attacks can have a very large scale and impact. For example, a malicious community plugin may potentially infect a large number of software systems built with Gradle. You can read more about such attacks and some examples in the following blog posts. During the past year, we at Gradle have been gradually ramping up our efforts to mitigate the risks associated with supply chain attacks. In the context of the Plugin Portal, our main objectives were: stronger enforcement of plugin domain ownership preventing plugin code dependencies from shadowing other, "real" dependencies of builds When a new plugin is published on the Gradle Plugin Portal it goes through a manual review process. This usually happens only for the initial version. A Gradle engineer inspects the metadata and decides whether to publish it to the portal or request changes to it. To give you a better understanding of what kind of sanity checks the engineer is doing, here are some examples: Is the plugin being published to misleading GAV (group, artifact, version) coordinates? Does the publishing user belong to the organization owning the plugin? Does the plugin have a clear and useful description? Does the plugin have the right tags? Is the link to the documentation valid and accessible? Even though this approach has been working pretty well, it unnecessarily increases the time it takes to provide feedback to plugin authors, either to fix problems they might have or to get their plugins published on