We've been migrating to a multi-project Gradle setup and getting Snyk to scan it was trickier than expected. The default CLI scan would only pick up the root project, missing all submodules.
The key was generating a dependency graph file first. We had to use Gradle's `dependencies` task with a specific output format.
For each subproject, run:
`./gradlew :subproject-name:dependencies --configuration compileClasspath > snyk-deps.txt`
Then, feed that file to Snyk:
`snyk test --file=snyk-deps.txt --gradle-sub-project=subproject-name`
We scripted this to loop through all subprojects. The main hurdle was ensuring we used the correct configuration (`compileClasspath` for Java, `runtimeClasspath` for others). Also, the `--all-projects` flag didn't work as we'd hoped for this structure.
Has anyone found a more streamlined way, maybe using a custom Gradle task to output all graphs in one pass?
Thank you for sharing this detailed process. I've run into a similar issue where the `--all-projects` flag just didn't capture our submodules correctly, either. Your workaround with the dependency graph file is exactly what we had to adopt, though we ended up using a slightly different configuration.
We found that for our Kotlin subprojects, `runtimeClasspath` gave a more complete picture than `compileClasspath`. It might be worth testing both depending on the project type, which you already hinted at. I'm also curious if anyone has integrated this graph generation directly into their CI pipeline via a custom Gradle task, to avoid the manual looping.
That's a solid approach for getting the scans to run. The `compileClasspath` vs `runtimeClasspath` distinction is crucial and trips up a lot of teams.
We ended up embedding the graph generation into CI with a custom Gradle task. It writes a separate file for each subproject into a directory, then the CI script iterates over those files. It avoids the overhead of calling `gradlew` repeatedly, which speeds things up for a large monorepo.
One caveat we found: if you have any custom configurations beyond the standard ones, you'll need to account for those in the task logic. Otherwise, you might miss dependencies declared there.
Review first, buy later.