Build Start Time

[asarkar]

Believe it or not, Gradle has never been able to tell precisely when the build started 😒.

APIs BuildListener.buildStarted and Gradle.buildStarted have been deprecated
These methods currently do not work as expected since the callbacks will never be called after the build has started.

This got worse with the introduction of Configuration Cache in Gradle 6.6, which made it illegal to use a BuildListener 😖. Previously, the build-time-tracker plugin used one of the BuildListener methods for an approximation of build started.

Plugins and build scripts must not register any build listeners. That is listeners registered at configuration time that get notified at execution time. For example a BuildListener or a TaskExecutionListener.

To their credit, Gradle has improved the Configuration Cache documentation, but it really seems that this feature was introduced without much impact analysis and migration guidance for plugin authors. 👎

gradle/gradle#18520

Thus, beginning with version 4.3.0, ⭐build-time-tracker no longer includes the time taken for the configuration phase⭐, and uses the oldest task start time as the build start time. In a way, this makes sense, because of the following reasons:

1. Most of the users are interested in knowing which tasks took longer to run, not how long the configuration phase took.
2. If using Configuration Cache, the configuration phase runs only once and hence the time taken is even less important.

If you've a comment or concern, please comment below. Also consider upvoting the issue above ☝️

---

Here's an example of using Configuration Cache and the tasks sorted in descending order of time taken:

import java.lang.Thread
import java.time.Duration
import com.asarkar.gradle.buildtimetracker.Sort
import java.time.LocalDateTime

plugins {
    id("com.asarkar.gradle.build-time-tracker")
}

tasks.register("a") {
    doLast {
        println("a sleep " + LocalDateTime.now())
        Thread.sleep(1100)
        println("a awake " + LocalDateTime.now())
        println("Hello, World!")
    }
}
tasks.register("b") {
    doLast {
        println("b sleep " + LocalDateTime.now())
        Thread.sleep(2100)
        println("b awake " + LocalDateTime.now())
        println("Hi there!")
    }
}
buildTimeTracker {
    minTaskDuration.set(Duration.ofMillis(100))
    sortBy.set(Sort.DESC)
}

Execution 1:

a sleep 2022-05-05T00:05:10.004587
a awake 2022-05-05T00:05:11.110470
Hello, World!
b sleep 2022-05-05T00:05:11.122668
b awake 2022-05-05T00:05:13.228216
Hi there!
== Build time summary ==
:b | 2S | 67% | ██
:a | 1S | 33% | █

Build duration is 3 seconds.

Execution 2:

b sleep 2022-05-05T00:05:13.457265
a sleep 2022-05-05T00:05:13.457230
a awake 2022-05-05T00:05:14.558365
Hello, World!
b awake 2022-05-05T00:05:15.562509
Hi there!
== Build time summary ==
:b | 2S | 100% | ██
:a | 1S |  50% | █

Build duration is 2, not 3, seconds. This is because with Configuration Cache enabled, all tasks run in parallel by default.

[asarkar]

https://docs.gradle.org/8.0/release-notes.html#configuration-cache

Starting in Gradle 8.0, tasks run in parallel from the first build when using the configuration cache.

Thus, the difference between first and subsequent runs shown above no longer exists.

[arifrgilang]

Hi @asarkar, thanks for this awesome plugin!

I have a quick question:
From what I understand, the plugin records the duration of each individual task. If I sum up all the task durations, it won't accurately represent the total build time, especially when org.gradle.parallel=true is enabled — is that correct?

Just wanted to confirm if this assumption is right. Thanks again for your work!

[arifrgilang]

Upon further checking this issue, I found that my question has already been answered.
Wouldn't it be better to state this clearly in the README.md—that the plugin doesn't track the actual total build time (especially when parallel execution is enabled), but instead only summarizes the time of individual tasks? Thanks

Hi @asarkar, thanks for this awesome plugin!

I have a quick question: From what I understand, the plugin records the duration of each individual task. If I sum up all the task durations, it won't accurately represent the total build time, especially when org.gradle.parallel=true is enabled — is that correct?

Just wanted to confirm if this assumption is right. Thanks again for your work!

[asarkar]

Hi, to better understand your question, I need more information. What do you think constitutes the "total build time" for the following cases?

1. When parallel build and configuration cache are disabled
2. When parallel build is enabled, but configuration cache is disabled
3. When configuration cache is enabled, but parallel build is disabled
4. When parallel build and configuration cache are both enabled

I've left out the build cache, which is different from the configuration cache, to keep things simple for now. I've also omitted parallel loading of configuration cache.

[asarkar]

BTW, the README does include a link to this thread.