Is there a way to get up-to-date Gradle start parameters with configuration cache?

Help/Discuss
1

What I try to achieve:
After the end of the build, I’d like to get the current Gradle start parameters.

Current behavior
After running a build that has a configuration cache with new parameters, the parameters from the previous run are returned from gradle.startParameter.<parameter>.

Expected behavior
Each build, gradle.startParameter returns up-to-date parameters.

Here’s reproduction (please check PluginTest): GitHub - wzieba/GetGradleConfigurationInPluginRepro . In this reproduction, I also experimented with FlowAction API, but unsuccessfully.

What’s also interesting, gradle.startParameter.taskNames seems to always be up-to-date

Probably related GitHub issue: Provide access to Gradle.StartParameter property value in a configuration cache compliant way · Issue #19474 · gradle/gradle · GitHub

My questions is:
Is it possible to somehow achieve my goal, which is to get the up to date Gradle start parameters with a build that uses configuration cache?

2

You probably have to use a ValueSource as when the result of it changes, the configuration cache is invalidated.

That it works with taskNames is clear, because configuration cache entries are bound to the set of requested tasks, so if you request other tasks, configuration cache is not reused.

For the other two, the printData in the apply is not executed on configuration cache reuse as configuration phase is skipped.

And the parameters of the flow action you also set during configuration time, so if the configuration cache is reused, also those values do not get set to a different value but are taken from configuration cache.

I guess that changing the value of configure-on-demand does intentionally not invalidate configuration cache, why should CC not be reused just because that option changes, the result should be the same. Whether it is the same for max-workers or whether it is there a bug, that CC is not reused I don’t know, but as this typically influences only execution logic on how many things to do in parallel at execution time, it could well be that this is intentional.

3

That it works with taskNames is clear, because configuration cache entries are bound to the set of requested tasks, so if you request other tasks, configuration cache is not reused.

Gotcha, I understand, thank you for clarification!

I guess that changing the value of configure-on-demand does intentionally not invalidate configuration cache, why should CC not be reused just because that option changes, the result should be the same.

I understand this motivation, it makes sense to not invalidate cache in most of the cases if configure-on-demand (or max workers) value changes. In my case, I want to get max workers to report it, so there’s a necessity to always have the up to date value of this parameter.

You probably have to use a ValueSource as when the result of it changes, the configuration cache is invalidated.

I’ve tried, but I’m not sure if it’s possible. My try looks like this:

abstract class MaxWorkersProvider : ValueSource<Int, MaxWorkersProvider.Parameters> {
    interface Parameters : ValueSourceParameters {
        @get:Input
        val startParameter: Property<StartParameter>
    }

    override fun obtain(): Int {
        return parameters.startParameter.get().maxWorkerCount
    }
}

but, unfortunately, it’s not possible to use as Could not serialize value of type StartParameterInternal. Is it something you had in mind, or you mean something different?

I’ve also experimented with

val maxWorkers = project.providers.systemProperty("org.gradle.workers.max").orNull?.toInt() ?: 0

which would fix the tests in the reproduction example, but it’s not suitable for real cases: I’d like to get max workers no matter if they were specified as an argument or not.

4

Hm, yeah, you’re right, there is probably nothing you can give as suitable parameter to the value source.
Then you might be lost. :-/
Maybe you can request a BuildFeature for is. :man_shrugging:

5

Then you might be lost. :-/

Yeah, I see :confused:. Nevertheless, thank you for your help! It clarifies that the feature I wanted to implement is not meant to work with CC.

Maybe you can request a BuildFeature for is. :man_shrugging:

Frankly, getting those parameters is not a big deal for my project. But I wonder about some other 3rd party plugins like Talaiot, as they also request some parameters, which change doesn’t invalidate CC (details).

1 Like