All dependencies are assigned to the settings.gradle.kts file

[JLLeitschuh]

Looking at the self-test results, all of the dependencies are being bound to the settings.gradle.kts file instead of binding the dependencies to the respective subproject's build.gradle.kts file.

https://github.com/gradle/github-dependency-graph-gradle-plugin/network/dependencies

For example, search for junit: https://github.com/gradle/github-dependency-graph-gradle-plugin/network/dependencies?q=junit

This dependency could be traced to either of these two locations:

• github-dependency-graph-gradle-plugin/plugin/build.gradle.kts

  Line 44 in 03dc2f1

  testImplementation(libs.junit.jupiter)

• github-dependency-graph-gradle-plugin/gradle/libs.versions.toml

  Lines 19 to 20 in 03dc2f1

  	junit-junit4 = { group = "junit", name = "junit", version = "4.13.2" }
  	junit-jupiter = { group = "org.junit.jupiter", name = "junit-jupiter", version = "5.10.0" }

However, neither of these files are linked to in the GitHub UI

[bigdaz]

FYI here's the commit that flattened the model to a single "manifest" for the entire build invocation.

Ideally, each resolved dependency version could be traced to the one (or several) places where it is declared. Unfortunately Gradle makes this very difficult to determine, and simply linking to the subproject that resolves a dependency (the previous behaviour) wasn't particular helpful if the version is defined elsewhere, like in a plugin or a .toml file.

BUT, linking the dependency to each subproject has the major downside of creating many more dependabot alerts for the project when this version needed upgrading. When working with real-world projects this made the Dependency Graph support much less useful, since the 100s of alerts generated led to users not trusting the tool.

So until we can reliably link a dependency version to the source file where it is defined, I'd prefer to point to the entire Gradle build (either settings.gradle or the root build.gradle), rather than try to guess a more specific location which might be incorrect.

[bigdaz]

BUT, linking the dependency to each subproject has the major downside of creating many more dependabot alerts for the project when this version needed upgrading. When working with real-world projects this made the Dependency Graph support much less useful, since the 100s of alerts generated led to users not trusting the tool.

To clarify this: imaging a Gradle build with 100 Java subprojects, and each subproject applies a convention plugin to configure the version of Junit used. In this case, we should be linking the junit dependency to the plugin sources as the single location where the version is defined.

But since we don't have a mechanism to do this, I don't think we should link this junit version to each of the subprojects that applies that plugin. Instead, we simply link the junit version to the entire Gradle build, relying on the users to determine which exact source file needs to be updated.

[JLLeitschuh]

BUT, linking the dependency to each subproject has the major downside of creating many more dependabot alerts for the project when this version needed upgrading. When working with real-world projects this made the Dependency Graph support much less useful, since the 100s of alerts generated led to users not trusting the tool.

Friendly ping to @jhutchings1 This seems like a bug, and/or a bad user experience for this feature.

Ideally, each resolved dependency version could be traced to the one (or several) places where it is declared. Unfortunately Gradle makes this very difficult to determine, and simply linking to the subproject that resolves a dependency (the previous behaviour) wasn't particular helpful if the version is defined elsewhere, like in a plugin or a .toml file.

This seems like something that could be tracked if the .toml file generated a richer Dependency object that included this information regarding declaring file, and this information was exposed all the way through the resolution event API.

Instead, we simply link the junit version to the entire Gradle build, relying on the users to determine which exact source file needs to be updated.

This seems like a reasonable "guess" could be made for a majority of cases, rather than always being incorrect by just using the settings.gradle file. This would be the principle of least surprise IMHO.

[JLLeitschuh]

So until we can reliably link a dependency version to the source file where it is defined, I'd prefer to point to the entire Gradle build (either settings.gradle or the root build.gradle), rather than try to guess a more specific location which might be incorrect.

🤔 I see your rationale, but I don't entirely agree. The dependency is tied to a specific subproject, and each subproject has a dedicated build.gradle file. Even if the dependency isn't declared in the build.gradle, it's still the file where that particular dependency is "managed" because it's the build.gradle for that project, and thus, the resolving configurations.

[jhutchings1]

BUT, linking the dependency to each subproject has the major downside of creating many more dependabot alerts for the project when this version needed upgrading. When working with real-world projects this made the Dependency Graph support much less useful, since the 100s of alerts generated led to users not trusting the tool.

Friendly ping to @jhutchings1 This seems like a bug, and/or a bad user experience for this feature.

Understood that this isn't ideal behavior, but we're not anticipating making any changes to the behavior of the API at this time.

[madisp]

adding to the discussion here - medium sized Gradle build, 49 modules, 1 extra included build. Dependency analysis is cool, but I have no clue where the deps are coming from as all of them say settings.gradle.kts. I would much rather have a bunch of dupes I can actually chase down.

Example: GitHub raised a warning about org.bitbucket.b_c:jose4j:0.7.0. I couldn't find it anywhere until it turned out it was a transitive dep of a Gradle plugin in the included build. Ended up running grep -R "jose4j" ~/.gradle/caches to get some idea where it was coming from.

[bigdaz]

Thanks for your comment. Were you aware of any of the additional documentation regarding "resolving dependency vulnerabilities"? (I'm wondering if there's a way to make these more prominent)

• https://github.com/gradle/github-dependency-graph-gradle-plugin?tab=readme-ov-file#using-the-plugin-to-generate-dependency-reports
• https://github.com/gradle/actions/blob/main/docs/dependency-submission.md#resolving-a-dependency-vulnerability
• https://github.com/gradle/github-dependency-submission-demo?tab=readme-ov-file#detecting-and-resolving-dependency-vulnerabilities-in-gradle-projects
• https://github.com/gradle/actions/blob/main/docs/dependency-submission-faq.md#why-arent-dependencies-be-linked-to-the-source-file-where-they-are-declared

Although I don't think it's practical to make it easy to attribute dependencies directly in the GitHub UI, we could also generate an extra, detailed report with full dependency-path information. Or we could possibly add the full dependency-path information as metadata in the GitHub Dependency Graph file.

[madisp]

Nope, I wasn't aware of those docs. I did manage to solve all of my issues by manually invoking the GitHub variant of the plugin locally though. I think the most ergonomic way for solving this would be perhaps exporting the generated .json file from GitHub Actions?

[bigdaz]

Thanks @madisp.
I've raised gradle/actions#195 to make this process easier in general.

[snuggie12]

We use renovate and was attempting to use the gradle dependency graph to auto-create PRs. The config passed to renovate come directly from this plugin. Therefore it is telling renovate to look in settings.gradle.kts for a specific dependency in order to substitute the string with an acceptable version.

I'm not a java developer, but best I can tell you can't declare dependencies inside of settings.gradle.kts short of maybe a catalog.

Would it be possible to make this file configurable? We don't have any subprojects so setting it to build.gradle.kts would give us an avenue to automate vuln fixing.