Versions of plugins from settings.gradle are not checked
See original GitHub issueSteps to reproduce:
- use Gradle 6.x
- add some plugin with old version to
settings.gradle(.kts)
for example “com.gradle.enterprise” - invoke
updateDependencies
task
plugins {
id("com.gradle.enterprise") version "3.1"
}
At the time of writing there is a version 3.1.1.
More info about build scan plugin: https://docs.gradle.com/enterprise/gradle-plugin/#gradle_6_x_and_later
Issue Analytics
- State:
- Created 4 years ago
- Comments:5 (3 by maintainers)
Top Results From Across the Web
Using Gradle Plugins
The plugin version is loaded from gradle.properties and configured in the settings script, allowing the plugin to be added to any project without...
Read more >plugins with apply false not checked · Issue #293 - GitHub
I use the following trick instead of the plugins block so that my plugin versions are located in with all of my other...
Read more >How to fix "plugin was not found in any of the following sources"
In a corporate environment if custom plugins can be presented in build files then a plugin repository URL, user & pass need to...
Read more >5. Add Gradle Plugin with Dependencies - Spring Cloud
To add a Gradle plugin with dependencies, you can use code similar to the following: Plugin DSL GA versions. // build.gradle plugins {...
Read more >Gradle | IntelliJ IDEA Documentation - JetBrains
Required plugins: Gradle, Gradle Extension (installed and enabled by default). The Gradle versions' support: starting with the version 3.0 ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Yes, if I recall correctly they use simple regex parsing of the build files rather than executing it. That has other limitations.
The long-term approach that Github/Gradle are pursuing is outlined in this proposal and github issue. This would be similar to having static analyzers produce SARIF reports that the Github Security dashboard consumes, so it could simply be an action that feeds the current dependency graph into Github for a monitoring dashboard.
Yes, see my comment above @nedtwigg. We would need to use both of those methods to capture those dependencies. Since those are not configurations, we’d have to make a detached configuration with the dependencies, repositories, and resolution strategy that those methods provide. Then resolve and print in the report with everything else.