Hey there I have a question regarding a problem we face with an enum in our build logic. We have this FeatureFlag enum in our build:

package 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?

is there any reason to be concerned, from a CC or IP perspective (or anything else), with usage of the

Project.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.

Hi everyone, Can anyone help me to solve this error? Could not determine the dependencies of task 'react native google paybundleLibCompileToJarRelease'.

Could not create task 'react native google paycompileReleaseJavaWithJavac'.

> In order to compile Java 9+ source, please set compileSdkVersion to 30 or above In my android/build.gradle,i have: buildscript { ext { buildToolsVersion = "34.0.0" minSdkVersion = 23 compileSdkVersion = 34 targetSdkVersion = 34 ndkVersion = "26.1.10909125" kotlinVersion = "1.9.22" } repositories { google() mavenCentral() } dependencies { classpath("com.android.tools.buildG8.2.1") // classpath("com.android.tools.build:gradle") classpath("com.facebook.react:react-native-gradle-plugin") classpath("org.jetbrains.kotlin:kotlin-gradle-plugin") } } apply plugin: "com.facebook.react.rootproject"

hello! I'm a maintainer of https://github.com/allegro/axion-release-plugin and I'm trying to update

project.version

after

release

task (in execution phase). It works when

configuration-cache

is disabled. I marked my

release

task as

notCompatibleWithConfigurationCache

. When

configuration-cache

is enabled, some other places have old version cached (like maven publication) - which is of course expected. Is it possible to "invalidate"

project.version

from cache? Or "exclude"

project.version

so this value alone wont be cached? Have you stumbled upon this problem? Example:

//...assuming maven-publish configured
version = "1"

tasks {
    register("changeVersion") {
        notCompatibleWithConfigurationCache("")
        doLast {
            version = "12345"
        }
    }
}

works:

./gradlew changeVersion publishToMavenLocal

doesn't work:

./gradlew changeVersion publishToMavenLocal --configuration-cache

Execution failed for task ':generateMetadataFileForPluginMavenPublication'.
> java.io.FileNotFoundException: ~/IdeaProjects/name/build/libs/name-1.jar (No such file or directory)

(name-1.jar instead of name-12345.jar)

I'm on a mission to fix as many project isolation issues as I can in third party projects. I fixed the trivial ones in KSP but there are some that are hard to fix. KSP needs to process the same source files as the normal compile task so it uses

sourceSet.kotlin

as an input. But since KSP generates source code which is in turn added to the sourceset they do this:

sourceSet.kotlin.nonSelfDeps(kspTaskName)

internal fun FileCollection.nonSelfDeps(selfTaskName: String): List<Task> =
    buildDependencies.getDependencies(null).filterNot {
        it.name == selfTaskName
    }

Calling

TaskDependency.getDependencies

is a PI violation. Is there another way to achieve the same result?

project isolation issue: Is

settings.gradle.allprojects

(and all APIs like it) incompatible with project isolation? I was thinking it was a valid API 🤔

With project isolation, will configuration cache writing/reading be done in parallel too?

👋 Bonjour à tous !

salut tout le monde

Quelqu'un peut m'aider a resoudre cet erreur FAILURE: Build failed with an exception. * What went wrong: A problem occurred configuring project ':libphonenumber'.

Could not create an instance of type com.android.build.api.variant.impl.LibraryVariantBuilderImpl.

> Namespace not specified. Specify a namespace in the module's build file. See https://d.android.com/r/tools/upgrade-assistant/set-namespace for information about setting the namespace. If you've specified the package attribute in the source AndroidManifest.xml, you can use the AGP Upgrade Assistant to migrate to the namespace value in the build file. Refer to https://d.android.com/r/tools/upgrade-assistant/agp-upgrade-assistant for general information about using the AGP Upgrade Assistant. * 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 8m 54s Error: Gradle task assembleDebug failed with exit code 1 Exited (1).

Do you have any idea how to make this task configuration cache happy?

val parallelCount = (Runtime.getRuntime().availableProcessors() / 2).takeIf { it > 0 } ?: 1
tasks.register("showParallelCount") {
  group = "Verification"
  description = "Show number of cores the test will be run on"
  doFirst {
    project.logger.warn("Tests will run on $parallelCount parallel JVMs")
  }
}

A separate issue, but I am also getting:

- Task `:jacocoTestReport` of type `org.gradle.testing.jacoco.tasks.JacocoReport`: cannot serialize Gradle script object references as these are not supported with the configuration cache.

Any ideas here?

so, I'm attempting to enable configuration cache for a project and it's failing because there

signArchives

invokes

Task.project

at execution time

tasks.withType<Sign>().configureEach {
    onlyIf { project.hasProperty("release") }
}

How shall this be transformed?

Publish a Gradle plugin to Gradle Portal is failing with configuration cache enabled

* What went wrong:
Execution failed for task ':semver-settings-gradle-plugin:publishPlugins'.
> Extension of type 'GradlePluginDevelopmentExtension' does not exist. Currently registered extension types: [ExtraPropertiesExtension]

any chance config-cache can be made more modular once we see isolated projects further along? IE: ability to config cache

includeBuild

projects used for gradle plugins even if the build including them is a miss?

Hi folks. Is there a CC-compatible substitute for the o.g.a.Project#project(String) method? My use-case is that I have a project reference as a String, like

:subprojectFoo

and I need to find its projectDir. I know that I should probably be providing this value as a task input but... it's complicated.

I have a

ValueSource

and its params interface. This interface is taking a

Property<VersionMapper>

, and this mapper extends

Serializable

.

interface Params : ValueSourceParameters {
        val versionMapper: Property<VersionMapper>
        ...
}

public fun interface VersionMapper : Serializable {

    public fun map(version: GradleVersion): String
}

But I am getting the next crash with config cache enabled:

> Could not create task ':playground-kotlin-version:printSemver'.
   > Could not isolate value com.javiersc.semver.project.gradle.plugin.valuesources.VersionValueSource$Params_Decorated@3cad81e8 of type VersionValueSource.Params
      > Could not serialize value of type Build_gradle..

I know the issue is around this

VersionMapper

because if I remove it from params, it works.

Related to the above, I am getting this error:

> Could not create task ':printSemver'.
   > Could not isolate value com.javiersc.semver.project.gradle.plugin.valuesources.VersionValueSource$Params_Decorated@6c6a363a of type VersionValueSource.Params
      > Could not serialize value of type $Proxy80

The problem is when the script is written in Groovy instead of in Kotlin.

semver {
   mapVersion { "1.0.0" }
}

Should I use something like

Transformer

instead my own

VersionMapper

interface? I think I would have the same issue with

Transformer

as that API does not extend serializable.

Hi 👋 What files should I look into for caching of environmental variables? I think I’ve found a bug. It’s put in backlog. To me, it sounds like a good first issue, but I have not found / understood where gradle caches environment variables. I have found platforms/core-configuration/configuration-cache/ and a bunch of files mentioning environment, like org/gradle/internal/cc/impl/services/Environment.kt. I’ve read some of them, but not all. Naively,

Environtment

does seem to cache all environment variables:

TrackingProperties(System.getenv()) // 👈 no input of which environmental variables the task depend on

But I’m unsure how to verify this. Where should I put a test like this?

fun `should bypass environmental variables that are not task dependencies when using configuration-cache`

And are there any similar tests that I can use as a template?

Hi folks. I've created a

Provider<String>

on a helper object which performs a semi-expensive shell-out the the terminal to fetch the version of a tool. I don't know why I thought this, but I expected the body of the method to be cached. Instead it is invoked each time I access the method. What am I doing wrong? Ideally the callable would be invoked once and the result cached each time I access

getExpensiveVersionOfLocalThing().get()

.

public Provider<String> getExpensiveVersionOfLocalThing() {
    return getProviderFactory().provider(() -> {
      // do expensive thing
      return expensiveResult;
    });
  }

Is there any advantage to using

providers.environmentVariable("FOO")

vs directly

provider { System.getenv("FOO") }

given that CC is invalidated on value changes in both cases?

Is

Provider.map {}

allowed with the configuration cache? I'm hitting a weird use case where it doesn't carry task dependencies:

val task1 = tasks.register("mytask1", MyTask::class) {
  myInput.set("input1")
  myOutputFile.set(layout.buildDirectory.file("output1.txt"))
}

val task2 = tasks.register("mytask2", MyTask::class) {
  myInput.set(task1.map { it.myOutputFile.get().asFile.readText() + "Suffix"})
  myOutputFile.set(layout.buildDirectory.file("output2.txt"))
}

output:

build/output1.txt (No such file or directory)

Is that a bug or am I using it wrong?

Is it possible to know if a dependent task has ran? A configuration-cacheable alternative to Task::getDidWork for cases where it’d be nice to know if, during the build, another task did work.

I am trying to create a task that enforces the usage of catalog dependencies if possible, so it checks if dependencies that could be used from the catalog were included using coordinates instead. I was able to do that by checking the classes of the dependencies to distinguish if a dependency comes from the catalog or not ( I needed to check an internal type but afaik that is the only way possible), but I am struggling to make that task compatible with the configuration-cache. I need something like this at task execution time:

project.configurations.getByName("testRuntimeClasspath").allDependencies

Configuration and DependencySet can not be cached but they will also not be properly populated at task configuration time. ResolvedComponentResult or ResolvedArtifactResult can be used via providers but those are dependencies already resolved and afaik they will not know if it comes from a catalog or not. Is there any way to make it work with the cache?

Hello, I have a question about isolated projects. I have just attempted to try it out on our multi-project gradle build. We have a nested structure with project names derived from the leaf folders. To avoid name clashes we have

build.gradle.kts

files in parent folders that look like this

allprojects {
    group = "unique-group-name"
}

This appears to break project isolation. Is there a recommended way of fixing this for project isolation?

👋 Is there a way to generate the report/peek at the content used for a configuration-cache entry? We’re trying to re-use configuration-cache entries in our ephemeral CI builds but a simple “tar up

.gradle/configuration-cache

and then un-tar it in the repeated run” has the configuration-cache not re-used with no other information presented in the scan

I don't want to hijack the above thread - @Nicklas Ansman does

--dry-run

give you an overall smaller transforms size while still providing config cache reuse?

Much much smaller.

It will produce transforms needed to configure the build as opposed to transforms needed to build your entire project