Bump gradle/actions/dependency-submission from 6.3.0 to 6.4.0

[dependabot]

Bumps gradle/actions/dependency-submission from 6.3.0 to 6.4.0.

Release notes

Sourced from gradle/actions/dependency-submission's releases.

v6.4.0

Highlights

Gradle version support status in the Job Summary

The actions now report the support status of every Gradle version used in a workflow, as job annotations and in the Job Summary (#1057). Thanks to @​ov7a for the contribution.

version kind	job annotation	version table	below the table
End-of-life — two or more major versions behind the latest release	warning	⚠️	expandable section naming the affected release lines, pointing at the Gradle Security Subscription
Out of date — one major behind, or more than two minors behind on the current major	notice	ℹ️	one-line legend pointing at the Gradle release lifecycle docs
Current	none	—	—

Deliberately not reported: patch releases (being on 9.7.0 when 9.7.1 exists is not flagged) and pre-releases (release candidates, milestones and snapshots never produce annotations). The latest Gradle release is determined from the wrapper checksum data already bundled with the action, so no network access is required.

Note that these annotations are emitted independently of the add-job-summary setting: setting add-job-summary: 'never' suppresses the Job Summary itself, but the warning and notice annotations remain.

Gradle itself is now reported in the dependency graph

The dependency-submission action now applies v1.5.0 of the GitHub Dependency Graph Gradle Plugin (up from v1.4.2) (#1069).

The headline change is that the Gradle Build Tool running the build is now reported as an org.gradle:gradle-core dependency, so that GitHub can surface known vulnerabilities in the version of Gradle used to run your build. These are the coordinates that GitHub advisories for the Gradle Build Tool are published against.

Details worth knowing:

• The entry is always reported as a direct dependency with development scope.
• It is not affected by the project, configuration or scope filters, so it appears even in graphs that filter aggressively.
• Expect dependency graphs to gain this one new entry the first time a build runs after upgrading.

A new Gradle signing key, if you use dependency verification

[!IMPORTANT] If your build has dependency verification enabled, you must add a second trusted key before upgrading, or Dependency Graph generation will fail signature verification.

github-dependency-graph-gradle-plugin 1.5.0 is signed with a new Gradle signing subkey, and the key previously documented in our setup guide has been revoked upstream:

... (truncated)

Commits

• 3f5f9ad Document the new Gradle signing key for dependency verification (#1071)
• b031f6d [bot] Update dist directory
• 5bc4175 Bump dependency-graph-gradle-plugin to 1.5.0 (#1069)
• f3ff59b Combined automated updates: wrapper checksums, npm dependencies, setup-java (...
• 7927085 Update .tool-versions: node 24.18.0, gradle 9.7.1, java 17 (#1068)
• c3897a4 [bot] Update dist directory
• 6b92be1 Update dependencies (#1065)
• 0d208da [bot] Update dist directory
• e49d0a3 Report EOL and maintenance status for Gradle versions (#1057)
• 575435b Use the root-qualified :wrapper task (#1064)
• Additional commits viewable in compare view