Karim Houari
01/16/2024, 3:35 PMartifactoryPublish
task is not compatible with the configuration cache. I have the following
artifactoryPublish {
notCompatibleWithConfigurationCache("")
}
but I am still getting an error "Configuration cache problems found in this build." when running artifactoryPublish
with a bunch of other errors such as > Invocation of 'Task.project' by task 'artifactoryPublish' at execution time is unsupported.
Any idea why this might be? Am I missing something?melix
01/17/2024, 4:03 PMserviceApi {
specProject = projects.micronautServiceSpec
}
the type of specProject
is Property<ProjectDependency>
, which is used in the plugin using:
task.getSpecFile().convention(extension.getSpecificationFile());
where getSpecificationFile
is mapped using:
openApiExtension.getSpecificationFile().fileProvider(
specConsumer.getIncoming()
.getArtifacts()
.getArtifactFiles()
.getElements()
.map(fileSystemLocations -> {
var specsDir = fileSystemLocations.iterator().next().getAsFile();
return new File(specsDir, serviceApiExtension.getSpecGroup().get() + "/" + serviceApiExtension.getSpecName().get() + ".yaml");
}));
and specConsumer
is a detachedConfiguration
which uses the project dependency:
var specConsumer = project.getConfigurations().detachedConfiguration();
specConsumer.getDependencies().addLater(serviceApiExtension.getSpecProject().map(p -> {
var copy = p.copy();
copy.setTargetConfiguration("processedSpecs");
return copy;
}));
Note how I'm using lazy APIs everywhere. Unfortunately this breaks with the configuration cache, with cannot serialize object of type org.gradle.accessors.dm.MicronautServiceSpecProjectDependency:clipboard:, a subtype of org.gradle.api.artifacts.Dependency:clipboard:, as these are not supported with the configuration cache.
ritesh singh
01/18/2024, 12:01 PMMichal Maruska
01/24/2024, 11:18 AMsed --silent 's/^.*totalProblemCount":\([[:digit:]]\+\),.*$/\1/p' $file
Is there an Api to somehow help with this (in the gradle build itself)?CristianGM
01/30/2024, 8:30 PMkotlinNpmInstall
) that reads Task.project during configuration time, and it's used to produce a task Input
• Without CC it works fine ✅
• With CC enabled it works fine ✅
• If I mark any other task in the build with notCompatibleWithConfigurationCache
the build fails complaining about this task ❌
◦ Invocation of 'Task.project' by task ':kotlinNpmInstall' at execution time is unsupported.
Jason Pearson
01/30/2024, 9:14 PM../../../../../usr/local/lib/android/sdk/platform-tools/.installer/.installData
has changed even though I’m ignoring that directory via my gradle.properties
Here’s a build that is showing this issue https://github.com/kaeawc/android-ci/actions/runs/7717496406/job/21036727699
Will try to get a build scan when I get a chance.Andrew Grosner
01/30/2024, 9:18 PMdependsOn
for a jacoco task. something like this:
project.allprojects {
tasks.withType(JacocoReport).configureEach {
if (it.name in jacocoTasks) {
jacocoFullReport.dependsOn(it)
}
}
}
would the best practice with project isolation to invert this, and have each subproject reference the root task and just register depends on there? my guess is yesAlexander Gherschon
02/01/2024, 4:10 AM1 problem was found storing the configuration cache.
- Task `:jacocoCoverageCheck` of type `org.gradle.api.DefaultTask`: invocation of 'Task.project' at execution time is unsupported.
Because of this code
val jacocoTasks = target.subprojects.flatMap { project ->
project.tasks.filter { it.path.endsWith(":jacocoTestReport") }
}
dependsOn(jacocoTasks)
So how can I depend on any tasks in any subproject that ends with a certain string, out of the config cache way?Martin
02/03/2024, 11:21 PMCould not load the value of field `transformer` of `org.gradle.api.internal.provider.TransformBackedProvider` bean found in field `provider` of `org.gradle.api.internal.provider.ValueSupplier$ChangingExecutionTimeValue` bean found in field `values` of `org.gradle.api.internal.provider.DefaultMapProperty$CollectingProvider` bean found in field `__downstreamUsedCoordinates__` of task `:root:generateServiceApolloSources` of type `com.apollographql.apollo3.gradle.internal.ApolloGenerateSourcesFromIrTask`.
[...]
Caused by: java.lang.ClassNotFoundException: com.apollographql.apollo3.gradle.internal.DefaultApolloExtension$registerSourcesFromIrTask$1$$Lambda$1732/0x00000008012f8c40
Now the weird thing is they fail only when withDebug(true)
(and when CC is enabled). If I run as a separate process, everything is good. Anyone with a clue something that changed in CC that could explain this?Zac Sweers
02/03/2024, 11:55 PMGRADLE_ENCRYPTION_KEY
was released in Gradle 8.6 but there's no canonical example of how to use it in a real project.
Seems like having a sample using something common would go a long way, especially as the docs don't which cache dirs should be preserved across machines to benefit from this. I know the first-party github actions have support for it, but it would be helpful for custom CIs to explain how it works.Marcin Robaczyński
02/05/2024, 12:38 PMgradle/actions/setup-gradle@v3
and noticed that the configuration-cache is still not reused on CI due to:
Calculating task graph as configuration cache cannot be reused because an input to task ':build-conventions:generatePluginAdapters' has changed.
As far as I know this task is cacheable and it runs fine on local builds. I wonder if there is something that I should cache separately?Ryan Schmitt
02/07/2024, 2:20 AMobtain()
) of a ValueSource
need to be serializable, right?Martin
02/07/2024, 1:06 PMfingerprint(lib/build/libs/lib.jar)
• or just something based on the project path? :lib
If I change a source file in :lib
(so the .jar contents changes), it shouldn't invalidate the CC for the whole build right?ibrehima keita
02/16/2024, 4:12 AM:workspaces:initQuerydslSourcesDir
of type `com.ewerk.gradle.plugins.tasks.InitQuerydslSourcesDir`: invocation of 'Task.project' at execution time is unsupported.
When enable this
org.gradle.unsafe.configuration-cache=trueJendrik Johannes
02/16/2024, 8:22 AMChristopher Enimil
02/23/2024, 11:30 AMSlackbot
03/01/2024, 9:15 PMZeeshan Shabbir
03/12/2024, 6:09 PMGRADLE_ENCRYPTION_KEY
on CI.
Now that I have added the GRADLE_ENCRYPTION_KEY
the cache was uploaded successfully but on next build when it tries to reuse it then it fails with following error.
Here are the highlights of this release:
- Configurable encryption key for configuration cache
- Build init improvements
- Build authoring improvements
For more details see <https://docs.gradle.org/8.6/release-notes.html>
Starting a Gradle Daemon (subsequent builds will be faster)
FAILURE: Build failed with an exception.
* What went wrong:
Could not load the value of field `parameters` of `org.gradle.api.internal.provider.DefaultValueSourceProviderFactory$DefaultObtainedValue` bean found in field `obtainedValue` of `org.gradle.configurationcache.fingerprint.ConfigurationCacheFingerprint$ValueSource` bean found in Gradle runtime.
> Failed to instrument class org/jetbrains/kotlin/gradle/plugin/internal/CustomPropertiesFileValueSource$Parameters in ClassLoaderScopeIdentifier.Id{coreAndPlugins:settings[:gradlePlugins]:buildSrc[:gradlePlugins]:root-project[:gradlePlugins]:project-dexGuardNoOpPlugin(export)}
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at <https://help.gradle.org>.
BUILD FAILED in 7s
I am unable to understand how to resolve this. Can someone explain what’s going on here and how I might be able to resolve this?Mario Quirós
03/21/2024, 10:36 PMCalculating task graph as configuration cache cannot be reused because the set of Gradle properties has changed
By looking at the error message, we noticed that something in the set of StartParams
changed from one build to the other. That is android.injected.build.abi
, which was the only diff.
The above is invalidating many of our local builds increasing our p50s. In most cases, the configuration phase needs to be executed again but the execution phase is UP TO DATE
, making the configuration times slower than the actual execution.
We are on Gradle 8.5 and AGP 8.2.2Philip W
03/26/2024, 10:49 AMCalculating task graph as configuration cache cannot be reused because an input to task ':build-logic:compilePluginsBlocks' has changed.
melix
04/15/2024, 3:56 PMdetachedConfiguration
with the configuration cache? I'm seeing something strange. Until now I had a task invoking project.getConfigurations().detachedConfiguration()
at execution time. Now, I replaced project.getConfigurations
with an injected property:
@Inject
protected abstract ConfigurationContainer getConfigurations()
The task still works if I don't use the configuration cache, but as soon as I enable it, it fails with:
> Some modules couldn't be updated because of the following reasons:
- awesome.lib:awesome:+ -> Cannot resolve external dependency awesome.lib:awesome:+ because no repositories are defined.
as if repositories were ignored...Justin Breitfeller
04/18/2024, 2:53 PMJavi
04/18/2024, 4:35 PMonlyIf
in the new develocity plugin
WARNING: Error invoking build scan publishingCondition action
Parameter specified as non-null is null: method com.javiersc.hubdle.settings.HubdleSettingsPluginKt.getHubdleSettings, parameter <this>
The relevant code is:
public val publishAlways: Property<Boolean> =
objects.property<Boolean>().convention(System.getenv("CI") == "true")
private fun Settings.configureGradleDevelocity() {
pluginManager.apply("com.gradle.develocity")
configure<DevelocityConfiguration> {
buildScan { scan ->
scan.publishing.onlyIf { hubdleSettings.buildScan.publishAlways.get() }
}
}
}
Javi
04/18/2024, 8:53 PMval catalog: VersionCatalog = versionCatalogs.named("hubdle")
val catalogDependencies: Provider<List<MinimalExternalModuleDependency>> = provider {
catalog.libraryAliases.mapNotNull { catalog.findLibrary(it).getOrNull()?.orNull }
}
val hubdleCodegen: TaskProvider<GenerateHubdleTask> =
tasks.register<GenerateHubdleTask>("generateHubdle")
hubdleCodegen.configure {
group = "build"
libraries.set(catalogDependencies)
libraryAliases.set(provider { catalog.libraryAliases })
pluginAliases.set(provider { catalog.pluginAliases })
}
But with config cache I get
* What went wrong:
Could not load the value of field `libraries` of task `:hubdle-gradle-plugin:generateHubdle` of type `com.javiersc.hubdle.logic.GenerateHubdleTask`.
> java.lang.NullPointerException (no error message)
Josh Friend
04/22/2024, 4:57 PM:foo:assemble
and save CC, then build :bar:assemble
and those two projects share numerous dependencies on other projects in the build, will there be any reuse of serialized configuration from the first command when running the second?Zeeshan Shabbir
04/30/2024, 1:43 PMCalculating task graph as the configuration cache cannot be reused because the environment variable '<Some env variable name>' has changed.
Upon investigation, we discovered that the root cause of this issue is the environment variables that are not exposed to the PRs.
Our current setup for the configuration cache involves creating it on non-PR builds via a workflow. This workflow triggers when any PR gets merged into develop, saving the cache. Subsequently, any new PR can utilize the configuration cache.
Do you have any recommendations on how we can resolve this issue? Is there any way we can ignore some variables for cache to so it doesn’t get invalidated. TIA!twisterrob
05/18/2024, 10:10 PMtasks.named("a").configure {
doLast {
if (tasks.named("b").map { it.state.failure != null }.get()) {
println("b failed")
}
}
}
Eug
05/27/2024, 11:42 AMRené
05/29/2024, 2:14 PMpackage org.elasticsearch.test.cluster;
import org.elasticsearch.test.cluster.util.Version;
/**
* Elasticsearch feature flags. Used in conjunction with {@link org.elasticsearch.test.cluster.local.LocalSpecBuilder#feature(FeatureFlag)}
* to indicate that this feature is required and should be enabled when appropriate.
*/
public enum FeatureFlag {
TIME_SERIES_MODE("es.index_mode_feature_flag_registered=true", Version.fromString("8.0.0"), null),
FAILURE_STORE_ENABLED("es.failure_store_feature_flag_enabled=true", Version.fromString("8.12.0"), null),
SEMANTIC_TEXT_ENABLED("es.semantic_text_feature_flag_enabled=true", Version.fromString("8.15.0"), null);
public final String systemProperty;
public final Version from;
public final Version until;
FeatureFlag(String systemProperty, Version from, Version until) {
this.systemProperty = systemProperty;
this.from = from;
this.until = until;
}
}
when building with configuration-cache enabled I see this error message:
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
at org.gradle.internal.concurrent.AbstractManagedExecutor$1.run(AbstractManagedExecutor.java:47)
Caused by: java.lang.IllegalStateException: Failed to create instance of org.elasticsearch.gradle.testclusters.ElasticsearchNode$FeatureFlag with args [es.index_mode_feature_flag_registered, 8.0.0, null]
at org.gradle.configurationcache.serialization.codecs.JavaRecordCodec.decode(JavaRecordCodec.kt:47)
at org.gradle.configurationcache.serialization.codecs.JavaRecordCodec$decode$1.invokeSuspend(JavaRecordCodec.kt)
... 163 more
Caused by: java.lang.NoSuchMethodException: org.elasticsearch.gradle.testclusters.ElasticsearchNode$FeatureFlag.<init>(java.lang.String,org.elasticsearch.gradle.Version,org.elasticsearch.gradle.Version)
at org.gradle.configurationcache.serialization.codecs.JavaRecordCodec.decode(JavaRecordCodec.kt:45)
... 164 more
It seems like a general serialisation issue with gradle. Is there anyting we can do from our side to work around / fix this issue?tony
06/18/2024, 6:51 PMProject.findProperty()
(and related) APIs? Tracing that code, it looks like a holdover from the old Groovy/dynamic days, as it accesses project "properties" hierarchically from closest to farthest, all the way back to the root if necessary.
use-case: it is pretty common in a lot of repos to have subproject/gradle.properties
files to define properties that aren't global. However, properties defined there aren't available via providers.gradleProperty()
, they're only available via project.findProperty()
and whatnot.