Is it just me, but ever since some version of grad...

# gradle

[ursus]

Is it just me, but ever since some version of gradle, whenever my code wont compile, I see the FAILED task, but build keeps going compiling probably until all work is done? Why? Its sometimes 10s of seconds wasted

> Task :clean
> Task :android-test-utils:clean
> Task :base-moshi:clean
> Task :base-di:clean FAILED
> Task :base-android:clean
> Task :base:clean
> Task :base-conductor:clean
> Task :base-coil:clean
> Task :auto-initialized-compiler:clean
> Task :base-net:clean
> Task :base-sqldelight:clean
> Task :auto-initialized-compiler:clean FAILED
> Task :global:clean
> Task :crashlytics:clean
> Task :base:clean FAILED
> Task :test-utils:clean
> Task :hashes:clean
> Task :regex:clean
> Task :formatter:clean
> Task :triggers-test-utils:clean
> Task :sqldelight-android-driver:clean
> Task :timestamp-parser:clean
> Task :usage-units:clean
> Task :activity-ui-helper:contract:clean
> Task :analytics:test-utils:clean
> Task :analytics:contract:clean
> Task :approvals:contract:clean
> Task :approvals:impl:clean
> Task :auth:test-utils:clean
> Task :analytics:exponea-tracker:clean
> Task :analytics:impl:clean
> Task :activity-ui-helper:impl:clean
> Task :payments-ui:clean
> Task :auth-flow:contract:clean
> Task :auth:contract:clean
> Task :auth:impl:clean
> Task :card-registration:contract:clean
> Task :chat:contract:clean
> Task :card-registration:impl:clean
> Task :auth-flow:impl:clean
> Task :chat:impl:clean
> Task :complex-syncer:test-utils:clean
> Task :config:config-api:clean
> Task :config:test-utils:clean
> Task :config:contract:clean
> Task :contacts:contract:clean
> Task :contacts:test-utils:clean
> Task :device-metadata:test-utils:clean
> Task :device-metadata:contract:clean
> Task :contacts:impl:clean
> Task :device-metadata:impl:clean
> Task :gdpr:impl:clean
> Task :gdpr:contract:clean
> Task :config:impl:clean
> Task :complex-syncer:contract:clean
> Task :in-app-review:contract:clean
....

and keeps going for 5minutes only to then print out red text that base-di:clean failed -- also, why on earth does clean fail is beyond me as well

[Vampire]

Do you maybe run with --continue? Because that's what it is doing. It continues to run all tasks that do not depend on the failed task to get as much errors in one run as possible. I usually do this on CI but not when running locally, except sometimes.

[ursus]

I'm not aware, I just hit the green hammer from android studio. How could I check?

[Vampire]

Add

println("gradle.startParameter.isContinueOnFailure = ${gradle.startParameter.isContinueOnFailure}")

to the build script and see what it prints.

[ursus]

So if I have a monorepo of multiple apps and I want to build all apps since I breakingly changed some core library, I should have a custom run configuration of gradlew app1:assembleDebug app2:assembleDebug etc ?

[ursus]

How would I do run configuration equivalent of gradlew app1:assembleDebug app2:assembleDebug ? This doesnt seem to work

[Vampire]

Why not?

[ursus]

it complains that the 2nd task doesnt exist, and also if i swap them then the 2nd one also doenst exists .. which tells me it seems to ready only until a space

[Vampire]

It should work just fine with multiple tasks and even arguments to tasks

[ursus]

is picking the gradle project as the root project okay?

[Vampire]

What do you mean with "as the root project"?

[ursus]

top level one; and then absolute paths to the 2 app modules assemble tasks

[Vampire]

You need to select that Gradle build that contains the tasks to run if you have connected multiple ones

[ursus]

yea thats fine

[Vampire]

As I said in the other slack, do you maybe have an MCVE where it does not work?

[ursus]

I'm sorry I'm an idiot and cannot type, it works as expected, sorry for wasting your time

[Vampire]

Don't worry :-)

[ursus]

however, I now need to "hardcode" the flavor in the task list, is there a way I could pick the current one selected in the IDE? Or should I just list all the flavored assemble tasks and let gradle optimize it?

[Vampire]

I have no idea about Android projects, sorry

[ursus]

I presume the common tasks will be optimized by the graph but probably it will build multiple apks per flavor, i.e. running each flavored assemble tasks

[ursus]

btw what is this? I hope these ide configuration use my gradle.properties (org.gradle.parallel=true)

[Vampire]

That has nothing to do with Gradle. It is whether you can start that run configuration while it is already running, independent of its type.

[ursus]

oh, great, thanks!

[ursus]

btw since I have you here, if I run gradlew command from command line, its a separate gradle daemon instance from IDE one and everything right? tasks caches are not reused, or is it?

[Vampire]

No, should usually be the same daemon. And even if it were different daemons, the cache is file based and would have been reused even then.

[ursus]

interesting, because usually terminal command are somewhat slower that ide

[Vampire]

Unlikely, but you could for example enable build scans and then have a look at the numbers

[ursus]

probably jsut a feeling

[dsvoronin]

I created an issue about the longstanding problem with “Build button” in Android Studio.
https://issuetracker.google.com/issues/203849144

@Zac Sweers i used your quote, if it’s not ok for you, please let me know, i’ll remove it

p.s. oh seems i can’t edit it 😞

[Zac Sweers]

no worries, though I think this is more of an intelliJ problem than studio