fossa-cli icon indicating copy to clipboard operation
fossa-cli copied to clipboard

Gradle analysis fails when Gradle's configuration cache enabled

Open 3flex opened this issue 3 years ago • 5 comments

The configuration cache is an incubating Gradle feature that can speed up Gradle runs. I believe it will become stable in Gradle 7.5, the next feature release.

The current init script used by fossa is incompatible with the configuration cache. This causes build failures when org.gradle.unsafe.configuration-cache=true is set in gradle.properties file in a project. See failed fossa-action run: https://github.com/detekt/detekt/runs/5807165493?check_suite_focus=true#step:3:1676 and associated Gradle build scan: https://gradle.com/s/yggz7hpzmzvyi

Options:

  1. Make the script compatible with the configuration cache
  2. Disable the configuration cache when running Gradle using --no-configuration-cache. This is tricky as the flag will only be recognised when the Gradle version is one that supports configuration cache i.e. Gradle 6.6 or higher.
  3. Disable the configuration cache using --no-configuration-cache when org.gradle.unsafe.configuration-cache=true is in the gradle.properties file. This might be risky as the configuration option name might change when the feature becomes stable.
  4. Allow end users to specify flags to pass to Gradle when the fossa jsonDeps task is run. That would allow passing the flag disabling configuration cache so the task succeeds.

Option 1 is preferred.

3flex avatar Apr 04 '22 12:04 3flex

Hi @3flex, thank you for filing this issue. I wasn't aware of these updates to Gradle, but they are promising and may greatly reduce our scan times going forward. This issue is now on our radar and we are looking into ways to patch this.

I agree that option 1 is the ideal way forward, however, I had some issues verifying that the issue lies with our plugin and not with the gradle cache. For example, I built your project and ran the native ./gradlew dependencies command and saw an identical error when you ran the fossa-cli. Do you see this error on your end as well or does it look like I'm doing something wrong to configure your project?

FAILURE: Build failed with an exception.

* What went wrong:
Configuration cache problems found in this build.

2 problems were found storing the configuration cache.
- Task `:dependencies` of type `org.gradle.api.tasks.diagnostics.DependencyReportTask`: cannot serialize object of type 'org.gradle.api.artifacts.Configuration' as these are not supported with the configuration cache.
  See https://docs.gradle.org/7.4.2/userguide/configuration_cache.html#config_cache:requirements:disallowed_types
- Task `:dependencies` of type `org.gradle.api.tasks.diagnostics.DependencyReportTask`: invocation of 'Task.project' at execution time is unsupported.
  See https://docs.gradle.org/7.4.2/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution

See the complete report at file:///home/groovy/detekt/build/reports/configuration-cache/7nc117jqrlaptdw7e2w80wocc/2kjgmb5mmiionmks9j4z4yjyb/configuration-cache-report.html
> Invocation of 'Task.project' by task ':dependencies' at execution time is unsupported.

This bit is the exact same error you are seeing in your build logs, except that gradle identifies "Task" as the source of the problem instead of "Initialization script":

- Task `:dependencies` of type `org.gradle.api.tasks.diagnostics.DependencyReportTask`: invocation of 'Task.project' at execution time is unsupported.
  See https://docs.gradle.org/7.4.2/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution

After some further investigation I found that the gradle cache cannot cache any tasks which use the Project object. Our gradle plugin uses the Project object which is what causes these failures, removing these objects should be possible given the resolution steps that Gradle gives, however if they are not, a combination of option 2 & 3 may be best.

Thank you again for filing the ticket and providing your open source project, this made it very straightforward to diagnose the root cause of the issue.

zlav avatar May 20 '22 00:05 zlav

Do you see this error on your end as well or does it look like I'm doing something wrong to configure your project?

You're not doing anything wrong, just be aware that configuration cache compatibility is determined individually for each task - if any tasks are incompatible, they'll be reported. It happens that :dependencies is not currently compatible (though it will be in Gradle 7.6), even though it's a Gradle core task.

Try ./gradlew assemble --configuration-cache on the detekt project and you'll see it succeed.

3flex avatar May 20 '22 11:05 3flex

It happens that :dependencies is not currently compatible (though it will be in Gradle 7.6) Thats really great to know

I will let you know when we have any updates for this issue. Tracked as ANE 329 internally

zlav avatar May 20 '22 19:05 zlav

Hello, could we just add the --no-configuration-cache argument to the gradle command that FOSSA runs? (The #2 option). We should be able to pull the gradle version for checking.

This would allow CI/CD pipelines that include a FOSSA step to not break if our projects implement configuration caching.

PenguinDan avatar Mar 07 '23 03:03 PenguinDan