Better support for multi-project repositories for `dependency-submission`

[ondrejfuhrer]

Description & Problem statement

Right now, it seems that the source file reported to the dependency submission API is settings.gradle (or build.gradle if that doesn't exist). It would be actually great if we can somehow make that more specific for multi-project setups. In cases where we have many projects defined which are included as Java libraries in different projects, it's actually quite hard to figure out from the security alert, which application / library is affected by an alert.

Possible solutions

Manual

One solution could be to manually set the resolved file location as a parameter, which would mean we have to run separately the submission job for each project (and only include that project in the report)

Pros:

• should be fairly easy to implement

Cons:

• A lot of manual work from the user perspective
• Requires execution of the same workflow for every gradle project

Automated through project resolution

The dependencies task returns project dependencies as well (that are labeled as project :xyz). This can be used to determine the build.gradle file that is used to define that dependency. That could be used to map out all the projects that live in the particular repository and submit the report with more explicit file source.

Pros:

• automated detection of projects
• precise reporting

Cons:

• Need to have a strategy to resolve same dependencies in multiple projects (not sure how GitHub API handles that)
• Fairly complicated resolution of projects

If there are any other options / solutions, I'm all ears 🙂

Goal

The goal here is to be able to easily find projects in multi-project gradle setups that have a certain dependency / security vulnerability.

[bigdaz]

In the original implementation, we attempted to attribute each dependency to the source file where it was declared. This turned out to be impractical. 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

We also tried creating a separate dependency graph for each subproject, but this was also problematic. Many dependencies are resolved in many different projects, and GitHub would treat each of these as a separate dependency usage. This would result in many duplicate security alerts being created. (Imagine a 100 project build where every project used dependency X: then 100 dependency alerts would be created).

We are working with GitHub to come up with a Dependency Graph model that is more suitable for Gradle. In the meantime, feel free to experiment with the Dependency Graph Plugin and see what can be generated.

[bigdaz]

I understand it's not ideal, but these docs demonstrate the current best practise for determining the underlying cause of a dependency alert: https://github.com/gradle/actions/blob/main/docs/dependency-submission.md#resolving-a-dependency-vulnerability

[ondrejfuhrer]

Thx for the explanation @bigdaz , I appreciate that. I was just thinking, that in the meanwhile if we enable that simply through "manual" setting from whoever is running the job (instead of hardcoded settings.gradle), might help in the meanwhile and doesn't sound like a big change 🤔 But it's not ideal at all, that I agree 🙂