Versions of plugins from settings.gradle are not checked

[koral--]

Steps 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

[ben-manes]

I suppose we would need to use Settings and evaluate both getBuildscript() and getPluginManagement().

[nedtwigg]

Closely related, it also does not check for these in the settings.gradle file:

pluginManagement {
  plugins { ...

[ben-manes]

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.

[jaredsburrows]

It looks like dependabot is able to do this: jaredsburrows/cs-interview-questions#29.

[ben-manes]

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.

[Vampire]

https://github.com/jmfayard/refreshVersions can also handle it, so would be nice to have it here too :-)

[ben-manes]

PRs welcome. 😁

[Vampire]

As always and everywhere :-D

[ianbrandt]

Just adding a use case, the Foojay Toolchains Plugin.

[ben-manes]

if someone wants to try this idea and send a pr that would be appreciated.

[Vampire]

Btw. imo pluginManagement { plugins { ... } } does not necessarily need to be checked. It's the same as plugins that are defined in a version catalog but not used anywhere. That block just defines versions that are used when a plugin later is applied without version. So if it is applied and thus used, it will already be covered (for project plugins already now, for settings plugins with this issue fixed).