Add support for dependency scope configuration (runtime vs development) in dependency-submission action

[diegocarba99]

The dependency-submission action currently submits all dependencies to GitHub's Dependency Graph API without any scope information. While the underlying GitHub Dependency Graph Gradle Plugin (in charge of actually building the dependency snapshot that's sent to the GitHub API) fully supports assigning runtime or development scopes to dependencies, the action does not expose any configuration options to enable this feature.

The Gradle plugin explicitly documents these environment variables as the way to configure dependency scopes in its README:

Controlling the scope of dependencies in the dependency graph

The GitHub dependency graph allows a scope to be assigned to each reported dependency. The only permissible values for scope are 'runtime' and 'development'.
[...]
By default, no scope is assigned to dependencies in the graph. To enable scopes in the generated dependency graph,
at least one of these parameters must be configured

However, the dependency-submission action does not expose these parameters, meaning users cannot differentiate between production runtime dependencies and development/test dependencies in their GitHub Dependency Graph—making it harder to prioritize security alerts.

This means that options like fail-on-scopes in actions/dependency-review-action (see here) are useless since scope information is not available in the Dependency Graph.

If scope information were to be included in Dependency Snaphots, the action would obtain alignment with GitHub's Dependency Submission API. The /repos/{owner}/{repo}/dependency-graph/snapshots endpoints supports scope, but we're not leveraging it

Current Behavior

All dependencies are submitted without scope, regardless of whether they are runtime or development dependencies.

The action exports DEPENDENCY_GRAPH_INCLUDE/EXCLUDE_CONFIGURATIONS and DEPENDENCY_GRAPH_INCLUDE/EXCLUDE_PROJECTS environment variables (sources/src/dependency-graph.ts#L40-L43), but does not export the scope-related variables that the Gradle plugin supports:

• DEPENDENCY_GRAPH_RUNTIME_INCLUDE_PROJECTS
• DEPENDENCY_GRAPH_RUNTIME_EXCLUDE_PROJECTS
• DEPENDENCY_GRAPH_RUNTIME_INCLUDE_CONFIGURATIONS
• DEPENDENCY_GRAPH_RUNTIME_EXCLUDE_CONFIGURATIONS

Expected Behaviour

Users should be able to configure which dependencies are marked as runtime vs development scope, either through:

1. Explicit action inputs, or
2. Sensible defaults that work out of the box for common Gradle projects

Workaround

Users can manually set the aforementioned environment variables when calling the action:

- name: Generate and submit dependency graph
  uses: gradle/actions/dependency-submission@v4
  env:
    DEPENDENCY_GRAPH_RUNTIME_INCLUDE_CONFIGURATIONS: '(compileClasspath|runtimeClasspath)'

This works, but is not documented and requires users to understand the underlying plugin's configuration.

Possible solution

Expose action inputs (like dependency-graph-runtime-<include/exclude>-projects or dependency-graph-runtime-<include/exclude>-configurations. Then, export them as the environment variables the GitHub Dependency Graph Gradle Plugin expects in sources/src/dependency-graph.ts#L31-L43 before calling it.

  core.exportVariable('DEPENDENCY_GRAPH_RUNTIME_INCLUDE_PROJECTS', config.getRuntimeIncludeProjects())
  core.exportVariable('DEPENDENCY_GRAPH_RUNTIME_EXCLUDE_PROJECTS', config.getRuntimeExcludeProjects())
  core.exportVariable('DEPENDENCY_GRAPH_RUNTIME_INCLUDE_CONFIGURATIONS', config.getRuntimeIncludeConfigurations())
  core.exportVariable('DEPENDENCY_GRAPH_RUNTIME_EXCLUDE_CONFIGURATIONS', config.getRuntimeExcludeConfigurations())

Sensible defaults could also be considered so the action adds the scope for the type of runtime configurations that are expected to be used at runtime.

• (compileClasspath|runtimeClasspath)

This would automatically mark production dependencies as runtime scope, while test and build dependencies would default to development scope.

Alternatively, the defaults could be left empty (current behaviour) to avoid breaking changes, with documentation guiding users to enable scope differentiation

Related

• Gradle plugin scope documentation: https://github.com/gradle/github-dependency-graph-gradle-plugin#dependency-scopes
• Note in current docs acknowledging this gap:

  actions/docs/dependency-submission.md

  Lines 267 to 269 in 4a417b5

  	> Ideally, all dependencies involved in building and testing a project will be extracted and reported in a dependency graph.
  	> These dependencies would be assigned to different scopes (eg development, runtime, testing) and the GitHub UI would make it easy to opt-in to security alerts for different dependency scopes.
  	> However, this functionality does not yet exist.