-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ci.queue_time for pipeline/stage/job traces #159
Conversation
// As the agent information will be stored in the Allocate node children | ||
// we need to propagate the information to the indexed span. | ||
for(final BuildPipelineNode parentIter : node.getParents()) { | ||
parentIter.setPropagatedSecondsInQueue(node.getSecondsInQueue()); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't follow that bit. We're propagating the time in queue of the curent node to each of its parent and we only do that to make the retrieval of that information easier later on, right?
What if a parent has multiple children and they all update the propagatedSecondsInQueue
? What about the time the parents themselves are in queue? There might be something I don't follow to understand fully this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, it might cause unexpected behaviour. I inverted the propagation approach, checking when the current node is the initial
or stage
and checking if its child is an Allocate node
node. Only in this case, we propagate the queue time.
This is needed because in Jenkins the queue time is calculated in this kind of nodes (Allocate node
), and not in the concrete Stage
/ Initial
node. We need to propagate all information to the correct nodes that will be indexed in the backend.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall, there's a core concept of that PR that I'm not sure to follow though. Would you mind giving more details about what it means for a node to be "in queue", why we're propagating that to parents etc.?
Sure. We consider that an item enters "in queue" when the item is "buildable" but it is waiting for some node to be scheduled to be built. For Jenkins Build, the solution is straightforward cause there is an API to obtain the queue time directly. Unfortunately for Jenkins Pipelines, the queue time is calculated under the nodes which name is the |
Requirements for Contributing to this repository
What does this PR do?
Add
ci.queue_time
for pipeline/stage/job traces in Jenkins Build/Pipelines.Description of the Change
Alternate Designs
Possible Drawbacks
Verification Process
Additional Notes
Release Notes
Review checklist (to be filled by reviewers)
changelog/
label attached. If applicable it should have thebackward-incompatible
label attached.do-not-merge/
label attached.kind/
andseverity/
labels attached at least.