Large GitHub dependency graph report kills the Dependency Graph view

[ParanoidUser]

Ahoy, Gradle team!

Congratulations on another exciting 2.6.0 release! Kudos to all the contributors for bringing GitHub dependency graph support to Gradle actions. 🙌🎉

Today, we learned that some dependency graph reports can be too heavy for GitHub to digest. Our project build ended up with a 25MB JSON snapshot that after submission killed the Dependency Graph view (hi, angry Unicorn 🦄) as now it takes too long to pull the data. While this may seem like a purely GitHub API-related issue with bulk response & timeout, we're looking for other possible solutions.

For example, our project includes a large collection of showcases (over 1300), each is defined as an independent subproject. Despite the large number of subprojects, there are only 7 direct dependencies + 3 plugins defined and shared across all of them. Because we manage the entire collection as a single shippable unit of software, it may be helpful to build a dependency graph report for just the top-level project that describes all 10 dependencies/plugins.

We would appreciate any insights or recommendations on this topic.

[bigdaz]

Thanks for trying out the new dependency graph support, and for your feedback.

First up, I'm happy that the action + plugin worked well even with such a large project: I haven't spent a lot of time optimizing performance and am currently unsure where things will start to break down.

It's unfortunate that GitHub doesn't cope so well with this graph, though. I'm in touch with the team responsible and will pass this on. The first thing you'll want to do is to clear the submitted results: you can use this sub-action of gradle-build-action directly or as an example to copy. The job.correlator value for your previous submission is "build_ci-scan".

Next, I suggest that you add a separate Job for dependency graph submission. This will allow you to choose an appropriate task to execute: one that will resolve the essential dependencies without resolving every subproject. I suggest starting with help and then trying dependencies and seeing what you get. (Note that the dependency-graph generated is completely determined by what dependencies are resolved during the build invocation).

[bigdaz]

I'm attaching the artifact file to this issue so it's retained for later analysis. dependency-graph-too-big.zip

[ParanoidUser]

Thank you for your prompt action and valuable input, @bigdaz! We'll take a closer look at these tasks. 👍

[bigdaz]

@ParanoidUser can you please try again with v2.6.1? The action/plugin now generates a flat graph of dependencies for the entire build, instead of being broken down by subproject. So your build should no longer produce a massive dependency graph.

[ParanoidUser]

Thank you for your time and consideration. It works magically! 🙌

Something unrelated to the topic. I suspect that the format of each dependency's status message is beyond our direct control. Despite the clear message that "unknown" source is confusing. Can we define it in any way?

[bigdaz]

Thanks for trying it out!

Despite the clear message that "unknown" source is confusing. Can we define it in any way?

I'm already in contact with the GitHub Dependency Management team about this. It appears it will require a backend change to make this work.