[🐛] Gradle plugins that register configuration on a root project break `snyk test --all-sub-projects`

[sarg]

• snyk -v: 1.736.0 (standalone)
• OS: OSX
• Command run: snyk test --all-sub-projects

Expected behaviour

no errors are produced

Actual behaviour

>>> stdout:
SNYKECHO snykResolvedDepsJson task is executing via doLast
JSONATTRS {"org.gradle.usage":["java-runtime","java-api"],"org.gradle.category":["library"],"org.gradle.libraryelements":["jar"],"org.gradle.dependency.bundling":["external"]}
SNYKECHO processing project: root-proj

>>> stderr:

FAILURE: Build failed with an exception.

* Where:
Initialization script '/var/folders/57/r31pm4zn2dngwxcrj__fz3gr0000gp/T/tmp-57859-g6BeQ14xfysD--init.gradle' line: 277

* What went wrong:
Execution failed for task ':snykResolvedDepsJson'.
> Matching configurations not found: .*, available configurations for project root project 'root-proj': [checkstyle]

Steps to reproduce

Put the following in gradle-multi-project build.gradle:

plugins { id 'checkstyle' }

[candrews]

To make this issue even easier to reproduce, I created an archive of a demo project: gradle-multi-project.zip

To make it:

• As described in the description, I took https://github.com/snyk/snyk/tree/master/test/acceptance/workspaces/gradle-multi-project
• I added the gradle wrapper (version 7.4)
• I made a couple modifications to to subproj/build.gradle to make it Gradle 7 compatible
• I edited build.gradle as described in the description

Here's the output of running snyk test --all-projects --fail-fast -d from within the project directory: snyk-output.txt

[candrews]

Snyk support suggested trying the --gradle-accept-legacy-config-roles argument. I added that argument but the result is the same.

Here's the output of running DEBUG=snyk-gradle-plugin snyk test --all-projects --fail-fast -d --gradle-accept-legacy-config-roles --print-deps from within the project directory: snyk-output---gradle-accept-legacy-config-roles.txt

[krzych-bristol]

@candrews: this may be a long shot, but here are the results of my investigation for something similar: we had a similar setup to yours where some of the plugins were defined/applied to the root project and child projects defined additional ones as needed. Up to the version of Spring Boot 2.3.12.RELEASE this setup caused as no issues, it worked with Snyk 1.645.0 and with 1.901.0 (latest) with Gradle 6.9.1/6.9.2. As soon as we upgraded gradle plugin in main root build.gradle to 2.4.0 and above the setup no longer worked.

Spring Boot version 2.4 introduces breaking config changes that need to be resolved with a help of this handy page Spring Boot Config Data Migration Guide

In order to track what was breaking I kicked the Snyk command (with debug) and noticed that at some point it will trigger snykResolvedDepsJson

./gradlew snykResolvedDepsJson -q --build-file build.gradle -Pconfiguration='^(?!test).*' --no-daemon -Dorg.gradle.parallel= -Dorg.gradle.console=plain -I init-snyk.gradle

the init-snyk.gradle is the copy of the file generated by Snyk from the successful run that sits in the tmp folder. I included more debug and I noticed that the result of filtering changes depending on the SpringBoot plugin version

print(proj.configurations);
                            if(filteredProjectConfigs.size() == 0) {
                                filteredProjectConfigs = proj.configurations
                                .findAll({ it.canBeResolved == true && it.canBeConsumed == true && it.name =~ confNameFilter  })
println('...AFTER SWITCH...')
print(proj.configurations)
print(filteredProjectConfigs.size())
print(filteredProjectConfigs)
                            }
                            projectConfigs =  configsSuccessfullyResolved(filteredProjectConfigs)

for everything below 2.4.0 we get:

[configuration ':bootArchives']
...AFTER SWITCH...
[configuration ':bootArchives']1[configuration ':bootArchives']

and for everything above:

[configuration ':bootArchives']
...AFTER SWITCH...
[configuration ':bootArchives']0[]

Since the projectConfigs var ends up with 0 nodes it then explodes further down the script with

throw new RuntimeException('Matching configurations not found: ' + confNameFilter +
                                ', available configurations for project ' + proj + ': '
                                + proj.configurations.collect { it.name })

To conclude, I did not find any solution to my issue aside from moving the gradle plugin application to the child projects. It's inconvenient and causes duplication but works. Lets hope this will help someone.