Introspection into "Waiting on concurrency group" status seems low

General
1

We’re adding a

steps:
  - label: ...
    command: ...
    concurrency: 1
    concurrency_group: "deploy/$KUBE_NAMESPACE"

restriction to one of our steps to ensure that deploys cannot happen in parallel if they’re modifying the same kubernetes namespace (the KUBE_NAMESPACE env-var).

It works great, and when a build is blocked, it’s somewhat clear why (if one knows to look in the Timeline tab, since it’s not displayed at the top level like the waiting-for-agents “Waiting …”):

image

However, once the build is unblocked, this event seems to disappear from the Timeline:

image

In addition, because there’s no top-level description, it’s confusing that a build where the individual steps take 8s + 18s + 1s + 3m 39s (= 4m 6s) apparently took 6m 49s to run overall. There doesn’t seem to be anyway to understand why there’s the 2m 43s difference between those times either, given the event has been lost.

image

Is there something I can do to enable more obvious logging (or similar) to keep track of this state permanently?

2

Hi @huon,

This discrepancy is something we’re working on improving right now, actually. That timeline is currently based upon the attributes on the job, not an actual timeline of events, however, we’ve recently begun storing those actual events and will soon be shipping an update to the UI which takes advantage of them, which will make this much clearer, and also allow us to better visualise and express the time taken in future.

1 Like
3

Ah, I see. Thanks for explaining. I look forward to any improvements! :smile: