When filtering by configuration, output does not agree with the Gradle dependencies task

[DavidGregory084]

Thanks for your work on this plugin!

I'm currently trying it out on one of my org's repositories (https://github.com/opencastsoftware/yvette) via the gradle-build-action integration.

I have noticed that if I set DEPENDENCY_GRAPH_INCLUDE_CONFIGURATIONS to runtimeClasspath, I get an empty manifest:

{
  "version" : 0,
  "job" : {
    "id" : "5656962664",
    "correlator" : "update_dependency_graph-submit"
  },
  "sha" : "eba0130d92ab95f6d1550ad9888bf7a834380ed3",
  "ref" : "refs/heads/main",
  "detector" : {
    "name" : "GitHub Dependency Graph Gradle Plugin",
    "version" : "0.2.0",
    "url" : "https://github.com/gradle/github-dependency-graph-gradle-plugin"
  },
  "manifests" : {
    "update_dependency_graph-submit" : {
      "name" : "update_dependency_graph-submit",
      "resolved" : { },
      "file" : {
        "source_location" : "settings.gradle.kts"
      }
    }
  },
  "scanned" : "2023-07-25T12:47:10Z"
}

This does not agree with Gradle's output:

❯ ./gradlew dependencies --configuration runtimeClasspath

> Configure project :
matching ref: BRANCH - main
ref configuration: BRANCH - pattern: .+
  describeTagPattern: v(?<version>.+)
  version: ${describe.tag.version:-0.0.0}-${describe.distance}-${commit.short}-SNAPSHOT

project version: 0.1.0-41-e5a6a57-SNAPSHOT

> Task :dependencies

------------------------------------------------------------
Root project 'yvette' - A diagnostic reporting library for Java
------------------------------------------------------------

runtimeClasspath - Runtime classpath of source set 'main'.
+--- org.fusesource.jansi:jansi:2.4.0
+--- org.apache.commons:commons-lang3:3.12.0
\--- org.apache.commons:commons-text:1.10.0
     \--- org.apache.commons:commons-lang3:3.12.0

It was necessary to set the variable instead to compileClasspath|runtimeClasspath as suggested in gradle/gradle-build-action#803 to see all of my project's dependencies, but it would be much more ideal if dependencies and this plugin could agree about the dependencies of a given configuration.

[big-andy-coates]

Hi @DavidGregory084,

I'm also playing around with DEPENDENCY_GRAPH_INCLUDE_CONFIGURATIONS. I noticed that in the docs on filtering it uses RuntimeClasspath not runtimeClasspath (upper vs lower case first letter). If you've copied the docs and used RuntimeClasspath, then this won't match any known configurations and, hence, you get no dependencies reported.

Worth checking!

Ref: gradle/gradle-build-action#840

[bigdaz]

@DavidGregory084 I'm going to assume that you were using the incorrect example from the docs, which specified RuntimeClasspath instead of runtimeClasspath (as described by @big-andy-coates above).

I'll close this issue, but feel free to comment here if you believe this issue requires further investigation.

[DavidGregory084]

Hi @bigdaz apologies I was on holiday last week!

I'm afraid that's not correct - this was the commit where I received an empty manifest when using runtimeClasspath as my configuration. As you can see, this matches up with the SHA recorded in the manifest.

[bigdaz]

Thanks for the link. When I forked your repo and enabled Build Scan publishing it was pretty obvious what's going on.

The Build Scan for this action run shows the full set of Configurations that were resolved when executing the build task: https://scans.gradle.com/s/miqukqhtjueso/dependencies?toggled=W1swXV0

You can see that runtimeClasspath isn't one of the resolved configurations, which explains why you saw nothing in your dependency graph. Perhaps compileClasspath would be a better example for the docs, since it's more likely to be resolved in a simple single-project build like this.

[DavidGregory084]

Ahhh that makes sense - I did not realise that configurations needed to be resolved out of band. Thanks for looking into this!