https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
t
doesn't 
./gradlew tasks
do this?
I guess that would probably trigger just the root 
tasks
task?
z
I have a specific task, when configured, throws an exception bc the tasks it depends on does not exist. but it creates this dependency lazily
Copy code
// in root `build.gradle.kts`
val configureAllTasks = tasks.register<Task>("configureAllTasks")

allprojects {
    configureAllTasks.configure {
        dependsOn(tasks.named("tasks"))
    }
}
I tried the above, but I got 
BUILD_SUCCESSFUL
g
tasks.all { .. }
or 
tasks.forEach { .. }
should do. If you want a it to be switchable -- hide it behind gradle property existence for example with 
if (providers.gradleProperty("blah").isPresent()) { .. }
.
👍 1
z
specially I have a task named: 
:featureSpoonDebugAndroidTest
Copy code
FAILURE: Build failed with an exception.

* What went wrong:
Could not determine the dependencies of task ':featureSpoonDebugAndroidTest'.
> Task with path ':feature:feature-ui:spoonDebugAndroidTest' not found in root project 'my-app'.
It groups 
Spoon
tasks for a feature across multiple subprojects. However, we’ve removed Spoon support already, but I missed this error bc CI stopped invoking 
:featureSpoonDebugAndroidTest
. I forgot to remove the code that registers 
:featureSpoonDebugAndroidTest
- and I want CI to catch this
@grossws I think your suggestion works! but I’m hitting other errors now, which is the whole point haha
e
at least in my builds, there are tasks that are expected to fail to configure except in specific environments, for example publish tasks that require credentials
z
yeah it’s a complicated problem @ephemient. I think there needs to be a difference between successfully configuring a task (which missing credentials should be allowed) vs it being scheduled for execution (should fail before execution)
👍 1
e
publish
with missing credentials definitely fails even with 
--dry-run
though, it's not a matter of failing at execution
z
I don’t mean failing at execution (which would be too late) - I’d want it to fail when it is going to be scheduled for execution. You wouldn’t want your library to build before reaching an error in that case @ephemient
also, with lazy configuration and the configuration cache - given the following:
Copy code
./gradlew task1
./gradlew task2
with lazy configuration, does 
:task2
necessarily benefit from the configuration cached from the invocation of 
:task1
?
(if not I’d personally rather configure everything up front and eat that cost then can skip the config phase entirely for every task invocation that follows)
g
You can just combine eager method like 
tasks.all
with some task like 
help
or 
tasks
. I don't see if separate API for it is viable.
👍 1
c
@Zak Taccardi about configuration-cache, no, CC stores a key with the command you run, so 
./gradlew task1
and 
./gradlew task2
don't share anything
v
Neither do 
gw task1
and 
gw task1 task2
afair
e
nor will 
./gradlew configureAllTasks
and 
./gradlew oneSpecificTask
, nor will 
./gradlew task1
and 
./gradlew t1
(abbreviation) afaik. I thought there was a ticket tracking that last bit but I can't find it
v
Also about
Gradle does not have an easy to use API
What is hard to use with 
allprojects.each { tasks.all { } }
?
Besides that the depending on tasks is not only an eager vs lazy problem. You can depend on a task by using its name alone and that will only be resolved when the task graph is calculated. You would not catch problems there even when configuring all tasks.
e
that would be detected by 
./gradlew --dry-run <list of all task names>
, but that fails on `publish`…
v
Indeed
6 Views
Open in Slack
PreviousNext
Powered by