Drupal/Gatsby: Build time tracking

[pmelab]

An extension to #521: Instead of just tracking a single state, the build trigger should log build time by tracking builds in a database table and show the expected build time (no, it won't be accurate) in the toolbar as a countdown.

[chindris]

Hi @pmelab and @Leksat ! I did a POC in https://github.com/AmazeeLabs/silverback-mono/pull/945 and I based the estimation on the data which is already logged in the gatsby_build_monitor_stats table.

In the toolbar I added a progress bar (not too fancy though) instead of a countdown. I was also facing another issue and want to double check with you: after a node gets saved, and a rebuild is triggered in the frontend, I would expect just two calls for the set state route, from the frontend to the backend: one to change the state to building, and one to change it to idle. However, I saw that there are 3 requests I get to set state to building. This affects that toolbar progress bar because each time when a state gets set, the progress bar would start from the beginning. So, is this thing also happening to you, or is it maybe something on my setup? I did spend a bit on debugging this, and apparently there are only two calls (one for building and one for idle) from the fast-builds/serve.ts script, so not sure where are the others from...

[Leksat]

One of our projects has the following stats:

• incremental builds take less than a minute
• builds with cache clear take more than 10 minutes

Let's imagine that average would be 2.5 minutes. In this case the progress bar will always be wrong.

As a client, I would not be really happy with this :)

I think we can make the prediction more accurate if we teach the Gatsby plugin to identify incremental and full builds. But I'm not sure if this is really possible.

[chindris]

@Leksat if the builds with cache clear do not happen that often, it is a high chance they are ignored. I know this is just an estimate and it will not be accurate all the time, and if we could somehow create two averages, one for incremental and one for full builds, it would be great. We could at least identify the incremental ones (when using the fast build __rebuild route), that would be an improvement. So, the average is probably to not be accurate for the builds with cache clear, because the algorithm is like this:

• consider the last 100 builds
• order the builds in an array (like if 10 build are taking 1 minute and 4 builds 2 minutes, those 10 builds will appear at the beginning of the array).
• ignore the second half of the array (this is the step where probably the builds with a cache clear, if they don't appear often, will be removed).
• compute the average.

But yes, if we could make this separation between the incremental ones and the full ones, it would be great.