Question: How do you handle baselining the original dependency tree?

[handstandsam]

This tool great, thanks for creating it.

I'm curious where you get the baseline dependency output that you compare the new dependency output? My thought was to have the ability for someone to re-baseline when a change occurred, and to keep the dependencies output under source control. That way you'd always see the diff in git, and you'd have something to compare to.

Thank you!

[JakeWharton]

The process is very similar to what I recommended for productionizing Diffuse.

On every CI build (whether for a PR or your trunk branch), capture the dependency tree output from Gradle and store it somewhere using the git SHA. This somewhere can be the local filesystem if you have a single CI machine, a shared NFS filesystem, or a cloud storage mechanism like AWS S3. You are using this storage mechanism like a database that is indexed by git SHA so the most important property is to be able to re-resolve the file using a git SHA.

On every CI build for a pull request, first compute the ancestor commit against your integration branch. This is done with git merge-base --all $PR_SHA origin/trunk where $PR_SHA is the git SHA of the latest commit on the PR and origin/trunk is your integration branch. That command will output another SHA, and this is the SHA you use to look up the old dependency tree from your storage location.

Now that you have the old dependency tree text file, you just need to run Gradle to produce the new dependency tree after which time you can use the tool to compare them.

This process of having a "database" of old dependency trees is much easier in practice than re-running Gradle using the merge-base commit. And since they're text file they are extremely small and cheap to store. And since no one will be branching from SHAs that are older than a few weeks, you can drop them after a few weeks so that the size and cost of storage remains relatively fixed.

[mateuszkwiecinski]

I can share my experiences I gained when integrating Jake's diffuse and dependency-tree-diff tools using Github Actions:
Setting up a reliable external storage turned out to be a bit challenging to me, so I decided to compute the old dependency tree on each pull-request, by simply checking out the pull-request base and generate the baseline on it. I created a dedicated Github Action for it: https://github.com/usefulness/dependency-tree-diff-action (if someone wants to check it out). Generating dependency tree on base commit takes a couple of seconds so it wasn't that much of an overhead and its advantage is the ease of integrating the tool with existing flow.

When I tried to integrate Diffuse I initially wanted to follow the same path, but it turned out to be a bit more challenging. Generating jar/apk/aab artifact was much more time-consuming. Given I didn't have dedicated external storage for produced artifacts I started using github action's cache and I can share what I ended up with: https://github.com/usefulness/diffuse-action#sample-create-pull-request-comment (that's exactly the flow Jake described in the comment above, implemented on Github Actions with Github Actions cache as the storage). It is less stable than dedicated storage as uploaded artifacts can be evicted outside of your control, but in most common case it works and doesn't require going outside Github Actions environment.