Closed sriyerg closed 3 years ago
So you're looking for the inverse of {percentage_0}
? That's doable. it would probably make sense to do the same thing for count_0
.
Right exactly - this would be an inverse of {percentage_0}
. To compute that, I think you will need the inverse of count_0
.
Just trying to nail down names for these fields. Currently working with count_00
and percentage_00
. Also considering:
percentage_sub
| count_sub
percentage_subs
| percentage_subs
There is also a counter property, subcount
, so subcount
and subpercentage
would be in line with that, but somewhat out of alignment with the other field names.
It's currently count_00
and percentage_00
in master. Please let me know if it works as expected.
Can confirm that this works in my examples as well. Thanks.
Implemented in 1.8.0
Is your feature request related to a problem? Please describe. This is related to the example provided in #41. Using the main counter
queued
to indicate the percentage of completion with{percentage}
leads to some discrepancy - progress bar shows 100% done even though jobs have not yet completed (either in passed failed or killed state). This behavior is technically correct, but its not reflective of the actual completion status. For long running jobs especially, there could be a big delta between progress bar indicating 100% and the jobs actually finishing. This may confuse the users.Describe the solution you'd like Currently, the only way to indicate the percentage is by selecting individual sub counters, or the main counter. It would be great to be able to indicate the percentage using the sum of all sub-counter counts instead, something like
{percentage_sum}
.