Prohibit BuildServiceProviders in configuration cache fingerprint#24099
Conversation
There was a problem hiding this comment.
🟡 I think used at configuration time is too generic and it might become a source of confusion but I don't have a better suggestion right now.
There was a problem hiding this comment.
I don't think it is possible to hit this without going through a ValueSource, but I might be missing something here, so I went with a generic term. "Fingerprinting" would be more precise, but we don't have it as a user-facing concept,AFAIK.
Custom ValueSource implementations may fail to serialize. Prior to this commit, the failure was attributed to "Gradle runtime" which is misleading. Now it is attributed to the build file or plugin that produces the input.
The typical way to make something an input to the configuration is to use the ValueSource, and then obtain its value at configuration time. Gradle recomputes these ValueSources when checking if the configuration cache is still valid. However, at this point not all build state is restored, but only a subset of it. This subset is not enough to restore BuildServices if these are used as ValueSource inputs. Before Gradle was failing the build with rather cryptic "cannot find project :" error, and only when running from the cache - the initial storing build was fine, even with load-after-store. With this commit, a special set of codecs is used to store the fingerprinting data, in which the BuildServiceProviders are explicitly not supported. This way we can detect the providers even in long mapping chains. We may revisit the decision and make it possible to use BuildServices in the future, but it requires a large rewrite of the fingerprinting code.
This is unlikely to happen, as this thing is hard to get as a configuration input anyway, so it is just-in-case.
1aa8fb6 to
ec99b69
Compare
|
@bot-gradle test ACC |
|
I've triggered the following builds for you: |
|
@bot-gradle test and merge |
|
I've triggered a build for you. |
| [[config_cache:not_yet_implemented:build_services_in_fingerprint]] | ||
| === Using build services to invalidate the configuration cache | ||
|
|
||
| Currently, it is not possible to use a `BuildServiceProvider` or provider derived of it with `map` or `flatMap` as a parameter for the `ValueSource`, if the value of the `ValueSource` is accessed at configuration time. |
There was a problem hiding this comment.
💄
| Currently, it is not possible to use a `BuildServiceProvider` or provider derived of it with `map` or `flatMap` as a parameter for the `ValueSource`, if the value of the `ValueSource` is accessed at configuration time. | |
| Currently, it is impossible to use a `BuildServiceProvider` or provider derived from it with `map` or `flatMap` as a parameter for the `ValueSource`, if the value of the `ValueSource` is accessed at configuration time. |
| === Using build services to invalidate the configuration cache | ||
|
|
||
| Currently, it is not possible to use a `BuildServiceProvider` or provider derived of it with `map` or `flatMap` as a parameter for the `ValueSource`, if the value of the `ValueSource` is accessed at configuration time. | ||
| The same applies such `ValueSource` is obtained in a task that executes as part of configuration phase, for example tasks of the `buildSrc` build or included builds contributing plugins. |
There was a problem hiding this comment.
💄
| The same applies such `ValueSource` is obtained in a task that executes as part of configuration phase, for example tasks of the `buildSrc` build or included builds contributing plugins. | |
| The same applies such as `ValueSource` is obtained in a task that executes as part of the configuration phase, for example, tasks of the `buildSrc` build or included builds contributing plugins. |
There was a problem hiding this comment.
@hythloda thank you for the review, I'll apply your suggestions in a follow-up PR.
Regarding this one, I missed a conjunction here, and intended to write "The same applies when such a ValueSource". Is it correct?
Fixes #22337