Display 2 times for builds, time spent queueing and time spent running

[seanhamlin]

There is an interesting situation right now, that if a deployment takes a long time to start (which can happen for numerous reasons, e.g. there is a queue of deployments ahead of the one you put through, and QoS is in place) the deployment times can jump around.

There are 3 times that are important for a deployment

• created - the time the deployment was queued to start
• started - the time the deployment actually started
• finished - the time the deployment completed

The UI shows the difference between created and now when the deployment is not yet complete, and started and finished when complete. This can cause the deployment times to jump upon completion. This is confusing.

Perhaps it might be best to show on the deployment 2 times upon completion:

• Time spent queueing
• Time spent executing

Perhaps in some easy to understand way. For bulk deployments, time spent queueing is not that important, but for regular single deployments it is.

[rocketeerbkw]

The UI shows the difference between created and now when the deployment is not yet complete, and started and finished when complete. This can cause the deployment times to jump upon completion. This is confusing.

It also shows the difference between started and now when the deployment has started. This is the point where the duration would reset to 0, not when it's completed.

Perhaps it might be best to show on the deployment 2 times upon completion

I disagree, IMHO; For a new deployment, a user might want to know two things 1) how long has a deployment been waiting 2) how long has a deployment been running. The current UI answers both these questions with the same duration column. You can think of the duration as tied to the status of the deployment instead of as an overall duration. For historical deployments, I don't care at all about how long they took to start, only how long it took to run. That way I can more accurately know if a deployment is taking longer than normal, or if the build performance improvements I made are working.

The "queue" time, as you call it, could be useful information in aggregate to glean cluster level resource management, but an individual developer won't be looking at that.

---

We could do user research to figure out if (1) is something users want at all. If the answer is no, we could not show a duration at all until a deploy starts. Or maybe we pull the "active" deployment off the top of the table into its own section that has all the timings.

[tobybellwood]

part of a larger "Lagoon Metrics" concept that tracks and reports all build metrics properly