This message was deleted.

you can't, I've seen this question asked before in this channel, but I can't find it

oof. that would suck if true. I tried searching in this channel but must not have hit the right search terms. I'll try scrolling instead...

i have it enabled by default in our checked in

gradle.properties

and in CI, i'm using

--no-configuration-cache

my use case is an internal developer beta program where we allow devs to opt-in to a set of leading edge changes. Using command line or committed gradle.properties values doesnt work for that, unfortunately.

i asked developers to opt-in using their User Home Gradle

yeah, I think that's the only fallback. I'll probably add manipulation of their gradle home properties into our opt-in/out tasks. 😞

You are asking how to produce an egg without a chicken. The scripts where you want to enable CC are not run with CC if reused, so enabling CC within them would be too late.

I'd imagine that would be true for everything except init scripts. The same logic would apply for enabling parallel execution, however this works from init scripts.

You don't listen, do you? Init scripts are part of configuring the build. If the configuration cache is reused, init scripts are not run but their effect reused. So even an init script is too late to enable the configuration cache. You can very easily test this with a

println("FOO")

within an init script. The only ways are

gradle.properties

, command line arguments, or a custom build where you add any other way. Parallel execution is galaxies far from configuration cache. Parallel execution is an option that only affects execution phase where tasks from different non-coupled projects are then run in parallel. Theoretically this option could even be switched during the configuration phase.

No need to be rude about a misunderstanding of what you were intending to convey

I'm not rude, I just asked whether you listened to what I said as I had to repeat because you said the opposite of what I just told you. If anyhting was rude, then that. 😉

The documentation says:

The configuration cache is a feature that significantly improves build performance by caching the result of the configuration phase and reusing this for subsequent builds. Using the configuration cache, Gradle can skip the configuration phase entirely when nothing that affects the build configuration, such as build scripts, has changed.

OP is trying to understand how the "configuration cache" caches something that's not part of the configuration phase, that's all

That's not at all what he asked though. He asked "how to set it from code" and I said "it is not possible, not even from init script". Then he said, "but it should work from init script" and I repeated that it is not possible from init script as it is also skipped when configuration cache is reused. I agree that the documentation is a bit misleading or has potential for misunderstanding. Init scripts as well as settings scripts are part of the initialization phase, not the configuration phase. But the docs do not say, that the configuration phase is cached. It says that the result of the configuration phase is cached. This includes any earlier phases like the initialization phase in which init and settins scripts are run. The result of the configuration phase are the tasks and their configuration and these are serialized to the configuration cache and on reuse restored from there.

It says that the result of the configuration phase is cached.

That's precisely the issue. By definition a cache is keyed based upon a particular input, that input supposedly being the output of the initialization phase. If there was no affordance for the inputs changing at all then the cached config would continue to be used indefinitely. That's obviously not the case. However, the current behavior is not taking into account the full behavior of the initialization phase and is oversimplifying the calculation of the cache key.

> It says that the result of the configuration phase is cached.

That's precisely the issue.

I personally don't see any issue there, besides that it is possible it is misunderstood. But feel free to open issues for things you think are wrong. I'm just a user like you.

By definition a cache is keyed based upon a particular input, that input supposedly being the output of the initialization phase.

This is neither said somewhere, nor is it implied anyhwere I can see.

If there was no affordance for the inputs changing at all then the cached config would continue to be used indefinitely. That's obviously not the case.

I'm not sure what you are trying to say. Init script content is part of the cache key, as well as build script content, settings script content, and all other things that make up the configuration cache input.

However, the current behavior is not taking into account the full behavior of the initialization phase and is oversimplifying the calculation of the cache key.

Why do you think so? The result of all phases up to before the execution phase are tasks and their configuration. And that is what is saved to and restored from the configuration cache iirc.

By way of example, the init scripts are documented as being useful to:

> - Set up properties based on the current environment, such as a developer’s machine vs. a continuous integration server.

In this case, a property is exactly one of the documented controls for configuring the config cache. If the init scripts don't run then that control cannot be effected. Hence, the surprise/disappointment.

Well, you are taking it too literally, or rather interpret it too strictly to back up your anger. That point just says that you can set up some properties based on the current environment. You can then use these properties in your build scripts. It does not say that you can change each and every property in an init script. Actually, you cannot set any Gradle property in an init script or build script or settings script and that statement also does not say so. The only way to currently set a Gradle property is through

build.properties

files and

-P

commandline arguments. And even if there were a way to set Gradle properties from an init script, there would be several ones that are simply impossible to set there as it is too late, like for example

org.gradle.debug

, or

org.gradle.jvmargs

, or

org.gradle.java.home

, ... You can often overlay Gradle properties by extra properties, but that also does only work if it is requested from the

project

like

project.property(...)

or similar, but it will for example not work if the consumer uses

providers.gradleProperty(...)

.

I should back up a half-step fore completeness. The inputs are documented as:

> Build configuration inputs include:

> - Init scripts, settings scripts, build scripts.

> - System properties, Gradle properties, environment variables used during the configuration phase

> - Configuration files accessed using value suppliers such as providers

> -

buildSrc

build configuration inputs and source files.

The oversimplification being that the behavior of the

Init scripts, settings scripts, build scripts

is fully contained in their file content with no affordance for branching logic.

What do you mean by "branching logic" here? And of course the file content is not all that is considered I think, their classpath for example is for sure considered too. If not, that is probably simply a bug.

Why do you think so?

The result of all phases up to before the execution phase are tasks and their configuration.

I think this entire discussion revolves around this point. I agree that configuration implicitly relies upon the result of all phases prior. That's where I see the problem: The result of the initialization phase is not being take into consideration because it is assumed that the result of the initialization phase (specifically WRT init scripts) cannot change without the init script content itself changing, whereas it may in reality take other data into consideration during its execution. Thus, the cached configuration, if reused, is based upon an inaccurate representation of the initialization. It's not really worth discussing further though. It is what it is at this point: Gradle's behavior does not currently rerun init scripts prior to cache key computation. Also, the only emotions I expressed were surprise and disappointment. There is no anger here.

cannot change without the init script content itself changing, whereas it may in reality take other data into consideration during its execution

Well, if that is true, I'd say that is a bug or missing feature and you should report it. After all, it is still an experimental features, so for sure still has some shortcomings. I would for example expect that if you use otherwise auto-detected external information like for example system properties, environment variables, or system properties, they are used as CC inputs too automatically. Or that you can define additional inputs like usual, using special providers methos or value source implementations. I didn't play much with init scripts and CC yet, so I'm not sure whether these things work / are possible. Can quite be that they are not yet possible or working, then you should open issues about them if there are none yet.

Or that you can define additional inputs like usual, using special providers methos or value source implementations.

I'm not quite to 7.5 yet but am interested in trying this out exactly this when I get there. It won't help my current conundrum but might ease the pain for more normal use in branching logic.

Thus, the cached configuration, if reused, is based upon an inaccurate representation of the initialization.

It's worth nothing that init script don't only impact initialization. They can also configure the projects. There's some naming issues at hand that are making things more confusing

True that. Although the naming issue isn't present in this case, settings also has this same characteristic. i.e., they both take part in initialization phase and beyond.

Unfortunately it seems the implied inputs like read environment variables, system properties and so on are also not considered when read from init script