Don't add onhold build time to the overall workflow time

circle.yml
workflow

#1

Currently when you use conditional workflows, the whole time spent on “hold” is added automatically to the workflow build time but this is misleading.

If we use conditional workflows, the time spent on “hold” should be recorded separately, or at least we should have a way to not record it at all.

This would be extremly useful to keep track of the build performance optimization for all projects that metrics matters.


#2

Hi.

Thanks for the feedback. The current workflow “duration” is based on wall time, which I think is still useful. Would an additional new value that’s the sum of all job durations, excluding manual gate jobs suit your needs?


#3

The sum of all jobs durations is not the same as the workflow duration, as some of jobs can run in parallel. The sum jobs duration wouldn’t be so useful, as we use parallel jobs to reduce the overall duartion.

But additional value which would be the workflow duration time excluding waiting time for manual approval would be perfect.


#4

@lewang, I think these values are useful:

  1. wall clock time (already available)

  2. Total container time consumed (this is a proxy for throughput - lower number here means higher throughput):
    For example:
    build A, parallelism 1, 30 seconds
    build B, parallelism 6, last container finished at 45 seconds
    Total = 1*30 + 6*45 = 300 seconds

  3. Longest path duration (I think this is what @swilgosz might be looking for) - find the path through the workflow that was the longest pole, assuming infinite containers were available. I’ve been calling this “latency” internally as the measure can be measured and computed regardless of load on Circle at any given time. This helps to highlight places where more parallelism could affect speed to build completion.

For example:
C depends on B
B depends on A
D depends on A
E is on its own

Dependency paths:
time(A) + time(B) + time©
time(A) + time(D)
time(E)

Which of the above took the longest, considering solely a sum of wall clock time on each “path”.


#5