This message was deleted.

Probably, yeah, as the

onlyIf

is checked at execution time.

I confirm :) The notion of execution time was a bit imprecise with regard to the getProject check before 8.1. It is now fixed, so there's a CC problem emitted, and not a silently incorrect build.

In that case then I'm guessing that the following line in the

onlyIf

is the culprit here:

project.gradle.taskGraph.allTasks.any { it.state.failure != null }

Is there an easy way to make that work with the CC? I'm not really familiar with this project and it is no longer maintained, so I'm looking for a quick and easy fix if possible 😅

Record the task state in an

OperationCompletionListener

and check that instead of the taskgraph?

Are you working on fixing that @Eli Graber? I've been working in that the whole day today, managed to some progress, but based on my tests

onlyIf

closures are now evaluated at configuration time and not at execution time, I am right? Maybe not configuration time, but definitely before the dependent tasks are run 🤔

You mean

a.finalizedBy(b)

but

b

should only run if

a

was successful?

Yes, but, the logic on

CommitEdit

is a bit hacky. It should commit the Play Store transaction if the dependents tasks where successful. But it should rollback (by calling

apiService.get().cleanup()

if they weren't).

I don't believe that without proof. 😄

You mean

a.finalizedBy(b)

but

b

should only run if

a

was successful?

Both, we need to change the behavior based on the outcome of previous tasks

Yeah, then have a build service that you register as operation completion listener where you record the outcome of the previous task and then use the build service's value to decide whether to commence or cleanup

I don't believe that without proof.

I put a breakpoint in the provider, look at the terminal, it's evaluated at

100% CONFIGURING

(when it's stored to cache) and without CC, it's evaluated just before the task is about to run, but after the other had run 🤔

And what do you do with that provider? Because here the counterproof:

tasks.configureEach {
    onlyIf {
        println("onlyIf for $name")
        true
    }
    doFirst {
        println("execution of $name")
    }
}

$ gw --configuration-cache build
Encryption of the configuration cache is enabled.
Reusing configuration cache.

> Task :processResources UP-TO-DATE
onlyIf for processResources

> Task :processTestResources UP-TO-DATE
onlyIf for processTestResources

> Task :compileJava UP-TO-DATE
onlyIf for compileJava

> Task :classes
onlyIf for classes
execution of classes

> Task :jar UP-TO-DATE
onlyIf for jar

> Task :assemble
onlyIf for assemble
execution of assemble

> Task :compileTestJava UP-TO-DATE
onlyIf for compileTestJava

> Task :testClasses
onlyIf for testClasses
execution of testClasses

> Task :test UP-TO-DATE
onlyIf for test

> Task :check
onlyIf for check
execution of check

> Task :build
onlyIf for build
execution of build

BUILD SUCCESSFUL in 17s
11 actionable tasks: 5 executed, 6 up-to-date
Configuration cache entry reused.

Not 100% sure right now, as I jump in into the project because we use this plugin as part of the CI. The full code is here but basically, it's

.get

is called as part of the

onlyIf

closure, added in a

init

method of the same task. The task is registered in the graph with

finalizeBy

by other tasks.

In that example the

prov

is probably state on the task and thus on serialization queried and persisted

FYI, I finally make it work by introducing

AutoCloseable

(to rollback) and

OperationCompletionListener

(to know if any previous task has failed) in the

PlayApiService

. Thanks a lot @Vampire for the hints!

I think the behavior is "any provider created while a task is configuring" is resolved at configuration time

No, the tasks state is serialized to CC. Providers are resolved at serialization time and their result serialized to CC. The

onlyIf

closure is part of the task and things it references are thus automatically also such state. In your case you reference the

prov

within

onlyIf

, so

prov

gets serialized, so that the

onlyIf

can access its value at execution time. And as

prov

is a provider, it is resolved at CC store time. If you add to your MCVE a

println("*** onlyIf called")

within the

onlyIf

you see that the

onlyIf

is indeed run at execution time. Just the provider is realized at CC store time.

dependsOn

, so that the finalizer task is only run on success.

That won't work as we have may "potential" tasks getting registerer/created. Adding

dependsOn

(to archive "only on success") will force all of them to run, just because one of team has run. I'm wondering if we need an API to complement

finalizedBy

to know about the outcome of its previous tasks 🤔 Clarifing, the plugin adds: • publishApk • publishBundle • publishStoreDetails (or similar, don't remember exactly) • etc, etc All of them are followed by

commitEdit

with

finalizedBy

but only if didn't fail. Adding the oposite

dependsOn

will force all of them to run. I couldn't find a way to archive the behavior with the current API, so I'm taking tracking their outcome in the

BuildService

and the

commitEdit

check if any has file as a

onlyIf

condition.

Ah, yeah, important detail you left out. 😄 Then, yes, the build service as operation completion listener that provides the relevant outcome is the way to go.