The setup-gradle action with dependency-graph option fails with Gradle Project Isolation

[hfhbd]

The dependency submission plugin is incompatible with Gradle 8.8-rc-1 due to its allprojects usage:

Configuration cache problems found in this build.

3 problems were found storing the configuration cache, 1 of which seems unique.
- Plugin class 'org.gradle.forceresolve.ForceDependencyResolutionPlugin': Project ':' cannot access 'Project.tasks' functionality on subprojects via 'allprojects'

See the complete report at file:///home/runner/work/adventOfCode/adventOfCode/build/reports/configuration-cache/jfejc8vffspgbktr0152humx/4r147d3lxn774c2lfhzsy7162/configuration-cache-report.html
> Project ':' cannot access 'Project.tasks' functionality on subprojects via 'allprojects'

Build Scan: https://gradle.com/s/mfuembswpbe7k
PR: hfhbd/adventOfCode#44

[bigdaz]

Thanks for the report. I'll ensure this gets fixed in some way before Gradle 8.8 is released.

[bigdaz]

Can you please test if this problem occurs with --no-configuration-cache as an additional argument?

[hfhbd]

After testing, it's not related to Gradle 8.8. I don't use the dependency-submission action but the setup action that has no additional-arguments as well as executes the dependency plugin during the regular build so disabling configuration cache won't only affect dependency submission but the whole build.

[bigdaz]

Can you please clarify how you are able to reproduce this issue? Are you applying the Dependency Graph plugin directly? Does this issue occur locally when you run the build?

[bigdaz]

I guess we should not be applying the ‘ForceDependencyResolutionPlugin’ when you are using the ‘setup-Gradle’ action.

[hfhbd]

No, I don't use the dependency plugin manually/locally, this is my workflow file: https://github.com/hfhbd/adventOfCode/blob/gradle88/.github/workflows/main.yml

[bigdaz]

You state that this is not related to Gradle 8.8. What change triggered the failure?

[hfhbd]

I used a separate workflow in the past but want to simply my workflows by "just enabling" the dependency-graph: generate-and-submit.

[hfhbd]

Or does enabling the dependency-graph: generate-and-submit in the setup-gradle only submit the dependencies used by the next Gradle execution only submitting the dependencies needed by the tasks? If this is the case, what's the purpose of opt-in in the setup-gradle action?

[bigdaz]

The option on ‘setup-gradle’ predates the ‘dependency-submission’ action, and it does something different: it uploads dependencies resolved during the subsequent Gradle builds.
I would recommend keeping a separate step that uses ‘dependency-submission’ which runs a particular task with well tested input arguments.

Note that you can now combine ‘dependency-submission’ and ‘dependency-review’ as sequential steps in the same Job.

[hfhbd]

Okay, got it. Thanks for the explanation and I will use the separate workflows again, it does work as expected.

Do you have any plans to deprecate the option in setup-gradle then?

[bigdaz]

Thanks for the explanation and I will use the separate workflows again, it does work as expected.

Note that you should be able to simply add an additional dependency-submission step to your existing workflow that executes Gradle. However, I just realized an issue that this will enable dependency-graph generation (but not submission) for any subsequent Gradle invocations.

Do you have any plans to deprecate the option in setup-gradle then?

Possibly. Just this morning I commented on an issue:
"I'm not (yet) sure if there's a good use case for having dependency-submission incorporated into the regular build process, as opposed to having it done in a dedicated Job/workflow."

Having a separate step that does nothing more than resolve and report dependencies is nice and simple, but a little wasteful compared to simply reporting the dependencies that were resolved in your existing Gradle build.

Submitting dependencies resolved in a "real" Gradle execution has a downside: if the build fails then possibly only a subset of dependencies will be reported. This could result in a vulnerability being "fixed", only to reappear the next time the build succeeds.

On balance, I think we should move toward a dedicated action that does not impact or interact with existing build processes. This could be an extra step in an existing workflow Job, or a separate Job. But I'm not ready to commit to this through deprecation just yet.

[bigdaz]

@hfhbd To close the loop on this:

• I can see from the Build Scan that the failing build had Project Isolation enabled
• As you reported earlier, the ForceDependencyResolutionPlugin is not compatible with project isolation.

Closing this issue as a duplicate.