https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
v
Also here a possible solution is the 
matching
way for the same price as described in the other thread.
z
It sounds like what I want to do here requires some pretty gnarly workarounds for what is conceptually a simple use case. I think I should maybe file an issue with Gradle here
e
Copy code
val order = listOf("task1", "task2", "task3", "task4")
tasks.configureEach {
    val index = order.indexOf(name)
    if (index >= 0) {
        shouldRunAfter(order.take(index))
    }
}
this shouldn't configure more tasks than would otherwise be configured
v
Ah, good idea, you just want to configure them and don't need the actual task collection, so 
matching
is not necessary of course. I tend to forget that 😞
z
oh nice. this is a good solution, but I don’t think it will work for tasks outside of the container? like picking up 
assembleDebug
on all subprojects
e
having non-dependency order between tasks is already a little eyebrow-raising, trying to do so across different projects sounds pretty fishy
v
Better just use configuration cache and a big CPU and have all tasks just run in parallel 😄
z
trying to do so across different projects sounds pretty fishy
does the use case make sense? currently we have CI run multiple separate Gradle CLI commands.
Copy code
./gradlew task1 // would be a formatting check, so important to run first for quick feedback
./gradlew task2
./gradlew task3
./gradlew task4
I want to move this to the following for things like a single build scan and better use of parallelization:
Copy code
./gradlew task1 task2 task3 task4
but preserve the ordering benefits of the separate CLI commands for quick feedback order
(I also don’t know if task dependencies are honored by 
shouldRunAfter
)
v
You shouldn't need anything special actually. If there is no dependency or ordering constraint between the tasks you give on the commandline, they should be run from left to right. (Unless parallel execution by 
--parallel
or 
--configuration-cache
is used of course, then it is more complex)
z
they should be run from left to right
is this documented anywhere?
v
I'm not even sure it is guaranteed, but it should at least be how it is currently. And if you really need ordering constraints you should set them so that they are also considered if you specify them in a different order on the commandline
z
this is solely for preferential execution ordering due to wanting to see feedback for task failures from certain tasks before others
v
Ah, turns out I was wrong, the opposite is documented
Gradle executes a build as fast as possible and that can mean that a task further right without dependencies might be executed earler than a task furhter left
z
a task further right without dependencies might be executed earlier than a task further left
this is actually fine and ideal. I would just want that whenever there is a free executor/worker to pick up a left-weighted task dependency before a right weighted task
v
Why is it then ideal that this might not be the case? confused
Well, whatever, if you really want ordering, declare it 🙂
z
it’s not strict ordering I want, I want that shouldRunBefore/After behavior
just to maximize parallelization and build failure feedback
the problem I have:
Copy code
./gradlew formatting
./gradlew assembleDebug
./gradlew build  // everything else
There’s a lot of time wasted in the above by unused executors, extra configuration time, and it also creates separate build scans for the same job. so I prefer:
Copy code
./gradlew formatting assembleDebug build
and if there is a free executor, I want Gradle to pick up a task dependency that is most left-weighted as possible
Like I wouldn’t want compilation to occur before formatting checks bc there should never be a free executor unless formatting checks complete as formatting checks can be maximally parallelized
but if compilation from 
assembleDebug
is running and there’s some free executors, I’d want Gradle to start executing a task dependency from 
build
(this might be the built in behavior)
Open in Slack
PreviousNext
Powered by