Fix: traceparent variable issue by Zenith1415 · Pull Request #1219 · jenkinsci/opentelemetry-plugin

Zenith1415 · 2026-01-19T01:07:35Z

Context

Fix for #1202.
Currently, the TRACEPARENT environment variable injected into the Groovy env object is stuck on the Root Span of the build. It does not update when entering new stages or nodes, breaking distributed tracing context for scripts that rely on env.TRACEPARENT.

Changes

Modified OtelEnvironmentContributor.java to use Span.current() instead of otelTraceService.getSpan(run).
Added a fallback: if no active span is found on the thread, it defaults back to the Run's root span.

Testing done

Reproduced the issue locally with a pipeline script. verified that env.TRACEPARENT now changes between stages.

Before Fix:
Stage 1: 00-abc...
Stage 2: 00-abc...

After Fix:
Stage 1: 00-abc...
Stage 2: 00-xyz...

Copilot

Pull request overview

This PR fixes a bug where the TRACEPARENT environment variable was not updating when entering new stages or nodes in Jenkins pipelines. The fix changes the implementation to use the current active span from the thread instead of always using the root span of the build.

Changes:

Modified OtelEnvironmentContributor to use Span.current() to get the active span on the thread, with a fallback to the run's root span if no valid span is found
Migrated ConfigurationKeyTest from JUnit 4 to JUnit 5 assertions

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
src/main/java/io/jenkins/plugins/opentelemetry/job/OtelEnvironmentContributor.java	Updated to use `Span.current()` instead of `otelTraceService.getSpan(run)` to capture the active span context, enabling TRACEPARENT to change between stages/nodes
src/test/java/io/jenkins/plugins/opentelemetry/semconv/ConfigurationKeyTest.java	Migrated from JUnit 4 (`org.junit.Assert`) to JUnit 5 (`org.junit.jupiter.api.Assertions`)

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

src/main/java/io/jenkins/plugins/opentelemetry/job/OtelEnvironmentContributor.java

src/test/java/io/jenkins/plugins/opentelemetry/semconv/ConfigurationKeyTest.java

src/main/java/io/jenkins/plugins/opentelemetry/job/OtelEnvironmentContributor.java

Zenith1415 · 2026-01-19T18:33:17Z

sorry for this, don't know how but i ran mvn spot less:apply before also, but i ran it again now, and commited only the required changes

kuisathaverat · 2026-01-19T19:04:49Z

The change needs a unit test to verify that the traces are correct and that the order is as expected.

Zenith1415 · 2026-01-19T20:03:29Z

@kuisathaverat I attempted to add a regression test using JenkinsRule and tried both Controller execution and a DummySlave agent, but the test fails to propagate the OpenTelemetry Context correctly in the test harness.
specifically, Span.current() returns the Root Span in the test environment, likely due to how JenkinsRule manages thread contexts compared to a real Jenkins production instance.
Since I have visually verified the fix on a running instance which you can see by the screenshots in the PR description showing env.TRACEPARENT updating correctly. I am happy to revisit the test if there is a known pattern for testing Span.current() in this plugin's test suite.

kuisathaverat · 2026-01-20T12:34:05Z

@kuisathaverat I attempted to add a regression test using JenkinsRule and tried both Controller execution and a DummySlave agent, but the test fails to propagate the OpenTelemetry Context correctly in the test harness. specifically, Span.current() returns the Root Span in the test environment, likely due to how JenkinsRule manages thread contexts compared to a real Jenkins production instance. Since I have visually verified the fix on a running instance which you can see by the screenshots in the PR description showing env.TRACEPARENT updating correctly. I am happy to revisit the test if there is a known pattern for testing Span.current() in this plugin's test suite.

The JenkinsRule works as a regular Jenkins (mostly). We have tests that verify traces in memory in other places, and the tests should be more or less similar. Without a unit test, we cannot validate the change.

Zenith1415 · 2026-01-20T12:40:44Z

@kuisathaverat I attempted to add a regression test using JenkinsRule and tried both Controller execution and a DummySlave agent, but the test fails to propagate the OpenTelemetry Context correctly in the test harness. specifically, Span.current() returns the Root Span in the test environment, likely due to how JenkinsRule manages thread contexts compared to a real Jenkins production instance. Since I have visually verified the fix on a running instance which you can see by the screenshots in the PR description showing env.TRACEPARENT updating correctly. I am happy to revisit the test if there is a known pattern for testing Span.current() in this plugin's test suite.

The JenkinsRule works as a regular Jenkins (mostly). We have tests that verify traces in memory in other places, and the tests should be more or less similar. Without a unit test, we cannot validate the change.

okay, working on it again !!

Zenith1415 · 2026-01-20T18:07:08Z

@kuisathaverat I attempted to add a regression test using JenkinsRule and tried both Controller execution and a DummySlave agent, but the test fails to propagate the OpenTelemetry Context correctly in the test harness. specifically, Span.current() returns the Root Span in the test environment, likely due to how JenkinsRule manages thread contexts compared to a real Jenkins production instance. Since I have visually verified the fix on a running instance which you can see by the screenshots in the PR description showing env.TRACEPARENT updating correctly. I am happy to revisit the test if there is a known pattern for testing Span.current() in this plugin's test suite.

The JenkinsRule works as a regular Jenkins (mostly). We have tests that verify traces in memory in other places, and the tests should be more or less similar. Without a unit test, we cannot validate the change.

so i have added a unit test file in it!

kuisathaverat · 2026-01-20T19:01:53Z

src/test/java/io/jenkins/plugins/opentelemetry/job/OtelEnvironmentContributorTest.java

+            mockedSpan.when(Span::current).thenReturn(currentSpan);
+            contributor.buildEnvironmentFor(run, envVars, listener);
+            // Verification
+            verify(environmentContributorService).addEnvironmentVariables(run, envVars, currentSpan);


The test does not verify the current change in the behavior.

kuisathaverat · 2026-01-20T19:01:59Z

src/test/java/io/jenkins/plugins/opentelemetry/job/OtelEnvironmentContributorTest.java

+            mockedSpan.when(Span::current).thenReturn(invalidSpan);
+            contributor.buildEnvironmentFor(run, envVars, listener);
+            // Verification
+            verify(environmentContributorService).addEnvironmentVariables(run, envVars, rootSpan);


The test does not verify the current change in the behavior.

Zenith1415 · 2026-01-20T19:26:21Z

I've updated the test to be more explicit about the behavior change.
In testBuildEnvironmentFor_UsesCurrentSpanIfValid , I added verify(otelTraceService, never()).getSpan(any());
This explicitly verifies that the code bypasses the old logic when a valid current span is present, which effectively verifies the fix.

kuisathaverat · 2026-01-20T21:26:05Z

src/test/java/io/jenkins/plugins/opentelemetry/job/OtelEnvironmentContributorTest.java

+            verify(environmentContributorService).addEnvironmentVariables(run, envVars, currentSpan);
+
+            // PROOF OF CHANGE
+            verify(otelTraceService, never()).getSpan(any());


It verifies that the method otelTraceService.getSpan(...) is never called when the current span is valid. But do not verify the spans of the step is the parant span and not the root span

kuisathaverat · 2026-01-20T21:26:19Z

src/test/java/io/jenkins/plugins/opentelemetry/job/OtelEnvironmentContributorTest.java

+            verify(environmentContributorService).addEnvironmentVariables(run, envVars, rootSpan);
+
+            // Verify that it was actually called the fallback service
+            verify(otelTraceService).getSpan(run);


Zenith1415 · 2026-01-21T03:28:01Z

I've updated the test to strictly verify the span identity.
In testBuildEnvironmentFor_UsesCurrentSpanIfValid , I now setup both a rootSpan and a currentSpan as distinct objects. I then verify that addEnvironmentVariables is called with currentSpan and addEnvironmentVariables is never called with rootSpan.
This explicitly proves that the step uses the current span and ignores the root span.

Zenith1415 · 2026-02-07T11:16:39Z

@kuisathaverat, Gentle ping

kuisathaverat · 2026-02-07T14:50:47Z

The requested changes on testing are not addressed. The test provided do not verify the context pass between layers in a pipeline.

Zenith1415 · 2026-02-07T15:18:35Z

Thanks for the feedback @kuisathaverat
I understand that the current test checks for negative behavior rather than explicitly verifying the context propagation.
I will rewrite the test to assert that the child span correctly inherits the parent's ID as requested. I have also manually verified the fix locally using a Jenkins + Jaeger setup, and the traces are now nesting correctly. I've posted the visual proof here:
https://community.jenkins.io/t/rfc-architecture-design-scalable-opentelemetry-for-jenkins/36060/2

kuisathaverat · 2026-02-07T18:43:52Z

Manual test does not remove the need of a proper test.

Zenith1415 · 2026-02-08T04:47:56Z

@kuisathaverat Thanks for the guidance. I have updated the PR with a new dedicated integration test that addresses your concerns.
Instead of relying on negative verification (verify(..., never())), this test now:

It creates a Root Span and a Child Span using the OpenTelemetry SDK.
It explicitly asserts that the injected TRACEPARENT environment variable matches the Child Span ID and is different from the Root Span ID.
I used Mockito.RETURNS_DEEP_STUBS to mock the ReconfigurableOpenTelemetry configuration, allowing us to test the OtelEnvironmentContributor logic without needing a full Jenkins instance.
I have verified this passes locally . This proves that the context is correctly switching between layers.

src/test/java/io/jenkins/plugins/opentelemetry/job/TraceParentIntegrationTest.java

…stages

Zenith1415 · 2026-02-10T05:12:35Z

@kuisathaverat Thanks for your review, this new test file created by me adds a regression test that validates TRACEPARENT propagation and span creation across nested pipeline stages, if there are any changes that to be done pls specifically guide me, also it passes mvn clean test perfectly.

src/test/java/io/jenkins/plugins/opentelemetry/job/TraceParentPipelineTest.java

Zenith1415 · 2026-02-10T12:41:21Z

@kuisathaverat i have added an extra step WithEnv, also a two stage check and try and catch block. also, it passes mvn clean test. Happy to do further adjustments if needed!

src/test/java/io/jenkins/plugins/opentelemetry/job/TraceParentPipelineTest.java

…PipelineTest.java

Zenith1415 · 2026-02-14T03:24:38Z

Applied the suggestion and pushed the update!

kuisathaverat · 2026-02-15T12:36:16Z

I need to verify an issue is not new (not related to this PR), before merging it and releasing it

kuisathaverat · 2026-02-15T19:23:46Z

I am testing the incremental version on main and the incremental of this PR and the change cause #1234

Zenith1415 · 2026-02-16T11:22:18Z

I think the propagation now links Jenkins internal operations to the pipeline span.
Happy to help, add filtering rules or reproduce the behavior locally if that helps.

ArpanC6 · 2026-03-19T05:16:12Z

Hi @kuisathaverat and @Zenith1415, I reviewed this PR and the
related issue #1234.

The concern about Span.current() linking Jenkins internal
operations to the pipeline span makes sense — in a multi-threaded
environment, Span.current() depends on the thread-local OTel
context, which may capture spans from Jenkins internals if they
happen to be active on the same thread.

One possible approach to investigate: could we check
Span.current() but also verify that the current span belongs
to the current pipeline run before using it? Something like
checking if the span's trace ID matches the run's root span
trace ID before preferring it over the root span.

This might prevent Jenkins internal spans from leaking into
the pipeline's TRACEPARENT while still fixing the original issue.

Copilot AI review requested due to automatic review settings January 19, 2026 01:07

Copilot started reviewing on behalf of Zenith1415 January 19, 2026 01:08 View session

Copilot AI reviewed Jan 19, 2026

View reviewed changes

kuisathaverat requested changes Jan 19, 2026

View reviewed changes

src/test/java/io/jenkins/plugins/opentelemetry/semconv/ConfigurationKeyTest.java Outdated Show resolved Hide resolved

src/main/java/io/jenkins/plugins/opentelemetry/job/OtelEnvironmentContributor.java Show resolved Hide resolved

Zenith1415 force-pushed the fix-traceparent-variable-issue branch from 6823eba to 03618fd Compare January 19, 2026 18:25

fixed changes requested

b72cbd8

Zenith1415 force-pushed the fix-traceparent-variable-issue branch from 03618fd to b72cbd8 Compare January 19, 2026 18:30

kuisathaverat reviewed Jan 20, 2026

View reviewed changes

Zenith1415 requested a review from kuisathaverat January 20, 2026 19:26

kuisathaverat reviewed Jan 20, 2026

View reviewed changes

Zenith1415 requested a review from kuisathaverat January 25, 2026 18:01

Test: Add integration test verifying context propagation between layers

7c1d73d

Zenith1415 force-pushed the fix-traceparent-variable-issue branch from ef25e0f to 7c1d73d Compare February 8, 2026 04:43

Fix: Remove incorrect imported class in same package

02f6e9d

Zenith1415 force-pushed the fix-traceparent-variable-issue branch from 2130fc2 to 02f6e9d Compare February 8, 2026 04:59

Fix code formatting violations

cc87aea

Zenith1415 force-pushed the fix-traceparent-variable-issue branch from 52a9bab to cc87aea Compare February 8, 2026 07:42

kuisathaverat reviewed Feb 9, 2026

View reviewed changes

src/test/java/io/jenkins/plugins/opentelemetry/job/TraceParentIntegrationTest.java Outdated Show resolved Hide resolved

Zenith1415 and others added 2 commits February 10, 2026 10:35

Added regression test for TRACEPARENT propagation in nested pipeline …

c05890b

…stages

Merge branch 'main' into fix-traceparent-variable-issue

c10773b

kuisathaverat reviewed Feb 10, 2026

View reviewed changes

src/test/java/io/jenkins/plugins/opentelemetry/job/TraceParentPipelineTest.java Outdated Show resolved Hide resolved

Zenith1415 added 2 commits February 10, 2026 17:52

Added WithEnv, multi stages and a try/catch case

9522f47

Added WithEnv, multi stages and a try/catch case

90ced8e

kuisathaverat requested changes Feb 13, 2026

View reviewed changes

src/test/java/io/jenkins/plugins/opentelemetry/job/TraceParentPipelineTest.java Show resolved Hide resolved

Update src/test/java/io/jenkins/plugins/opentelemetry/job/TraceParent…

135aa50

…PipelineTest.java

kuisathaverat added the bug Something isn't working label Feb 15, 2026

kuisathaverat assigned Zenith1415 Feb 15, 2026

kuisathaverat approved these changes Feb 15, 2026

View reviewed changes

Conversation

Zenith1415 commented Jan 19, 2026

Context

Changes

Testing done

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Zenith1415 commented Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kuisathaverat commented Jan 19, 2026

Uh oh!

Zenith1415 commented Jan 19, 2026

Uh oh!

kuisathaverat commented Jan 20, 2026

Uh oh!

Zenith1415 commented Jan 20, 2026

Uh oh!

Zenith1415 commented Jan 20, 2026

Uh oh!

kuisathaverat Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

kuisathaverat Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

Zenith1415 commented Jan 20, 2026

Uh oh!

kuisathaverat Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

kuisathaverat Jan 20, 2026

Choose a reason for hiding this comment

Uh oh!

Zenith1415 commented Jan 21, 2026

Uh oh!

Zenith1415 commented Feb 7, 2026

Uh oh!

kuisathaverat commented Feb 7, 2026

Uh oh!

Zenith1415 commented Feb 7, 2026

Uh oh!

kuisathaverat commented Feb 7, 2026

Uh oh!

Zenith1415 commented Feb 8, 2026

Uh oh!

Uh oh!

Zenith1415 commented Feb 10, 2026

Uh oh!

Uh oh!

Zenith1415 commented Feb 10, 2026

Uh oh!

Uh oh!

Zenith1415 commented Feb 14, 2026

Uh oh!

kuisathaverat commented Feb 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kuisathaverat commented Feb 15, 2026

Uh oh!

Zenith1415 commented Feb 16, 2026

Uh oh!

ArpanC6 commented Mar 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Zenith1415 commented Jan 19, 2026 •

edited

Loading

kuisathaverat commented Feb 15, 2026 •

edited

Loading