feat: add queue phase spans to build traces - #1286
Open
rahulsom wants to merge 2 commits into
Open
Conversation
rahulsom
force-pushed
the
feat/queue-phase-spans
branch
2 times, most recently
from
May 2, 2026 23:29
9244f61 to
dd552c0
Compare
rahulsom
marked this pull request as ready for review
May 3, 2026 00:06
rahulsom
force-pushed
the
feat/queue-phase-spans
branch
3 times, most recently
from
May 28, 2026 16:33
a9dfa89 to
0c91a40
Compare
rahulsom
force-pushed
the
feat/queue-phase-spans
branch
from
June 1, 2026 16:24
0c91a40 to
1e5f26b
Compare
rahulsom
force-pushed
the
feat/queue-phase-spans
branch
from
June 9, 2026 19:28
1e5f26b to
2063e14
Compare
The cloudbees-disk-usage-simple plugin refreshes disk usage on a
background thread and persists cloudbees-disk-usage-simple.xml into
JENKINS_HOME when it finishes. When that write lands while
JenkinsRule.after() is deleting the temporary JENKINS_HOME, deletion
fails with DirectoryNotEmptyException ("These files still exist:
cloudbees-disk-usage-simple.xml") and the otherwise-passing test is
reported as a failure. The flake hits random integration tests and also
occurs on the main branch.
BaseIntegrationTest.afterEach() now forces the refresh to completion
before JenkinsRule teardown: it flushes any in-flight write and bumps
the plugin's lastRunEnd so its 15-minute quiet period suppresses any
further refresh during teardown.
Before this change, traces only covered build execution. Builds that spent time waiting in the Jenkins queue showed up with a root span whose start time matched execution start, hiding all queue latency. This change attaches a QueueItemMonitoringAction to each queue item as it enters the WaitingItem state. The action tracks each state transition (Waiting → Blocked → Buildable) with timestamps and the reason/label for that state. When the build starts, MonitoringRunListener reads the completed phases and emits a child span per phase under the root BUILD span, using historical timestamps. The root span start time is extended back to when the item first entered the queue. New spans: Phase: Queue - Waiting (ci.pipeline.run.queue.reason, when applicable) Phase: Queue - Blocked (ci.pipeline.run.queue.reason, jenkins.pipeline.step.agent.label) Phase: Queue - Buildable (ci.pipeline.run.queue.reason, jenkins.pipeline.step.agent.label)
rahulsom
force-pushed
the
feat/queue-phase-spans
branch
from
June 9, 2026 20:40
2063e14 to
2a38cef
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Before this change, traces only covered build execution. Builds that spent time waiting in the Jenkins queue showed up with a root span whose start time matched execution start, hiding all queue latency.
This change attaches a QueueItemMonitoringAction to each queue item as it enters the WaitingItem state. The action tracks each state transition (Waiting → Blocked → Buildable) with timestamps and the reason/label for that state. When the build starts, MonitoringRunListener reads the completed phases and emits a child span per phase under the root BUILD span, using historical timestamps. The root span start time is extended back to when the item first entered the queue.
New spans:
Testing done
Added tests.
Manually verified the spans are present.
Submitter checklist