Stable CI & Jenkins Semantic Conventions

[cyrille-leclerc]

Review our semantic conventions to head toward interoperability with other CI/CD platforms.

Current source code:

• https://github.com/jenkinsci/opentelemetry-plugin/blob/opentelemetry-0.9/src/main/java/io/jenkins/plugins/opentelemetry/semconv/JenkinsOtelSemanticAttributes.java
• https://github.com/jenkinsci/opentelemetry-plugin/blob/opentelemetry-0.9/src/main/java/io/jenkins/plugins/opentelemetry/semconv/JenkinsSemanticMetrics.java

More on semantic conventions for CI/CD

• CD Foundation / SIG Interoperability / Vocabulary

[cyrille-leclerc]

Change milestone from v1.0 to later as we don't want to block 1.0 for this standardisation task that will take time aligning with other CI/CD platforms.

[kuisathaverat]

open-telemetry/oteps#223

[kuisathaverat]

open-telemetry/semantic-conventions#1075

[kamphaus]

Semantic Conventions v1.33.0 added semantic conventions for spans and resource entities.

I think adopting the cicd conventions for spans would not be too difficult: just renaming some attributes in pipeline and step spans.

However the resource conventions would require some refactoring and require either instantiating multiple Otel SDKs or waiting for open-telemetry/opentelemetry-specification#4665.

[kuisathaverat]

It is not just a renaming, the solution adopted must be backwards compatible and not the default for a few months to allow users to adapt their backend to the new data structure. If we do it in another way, we break the users' backends.

[kamphaus]

In #1096 I saw the property otel.semconv-stability.opt-in for determining which metric names to use.

Given that the CICD SemConv is not yet stable there might yet be further changes (I hope not).
I would compare otel.semconv-stability.opt-in against the following values: cicd_latest_experimental, cicd_latest_experimental/dup with default behavior not emitting otel conventions.
What do you think?

[kamphaus]

I discussed the OTEL_SEMCONV_STABILITY_OPT_IN mechanism in the OpenTelemetry SemConv SIG:
open-telemetry/semantic-conventions#3262

The use of OTEL_SEMCONV_STABILITY_OPT_IN in areas of http, rpc is due to those conventions having remained in experimental state for a long time and thus having become defacto stable.
Since the OpenTelemetry CICD SemConv is young and hasn't had any major breaking changes yet, using a flag in OTEL_SEMCONV_STABILITY_OPT_IN does not seem necessary.
How vendors want to adopt the OpenTelemetry CICD SemConv is up to the vendor (breaking change, opt-in).

Given this feedback do you still want to use otel.semconv-stability.opt-in as the flag for opting-in to Otel CICD?
If so, maybe instead of cicd_latest_experimental the following values would be better:
jenkins_to_cicd_experimental and jenkins_to_cicd_experimental/dup
These values would ensure that there is no conflict if SemConv would define a cicd flag at a later time.

[kuisathaverat]

Since the change, it is a change of behaviour that uses the current Jenkins semantics, or the Otel CICD SemConv, or both, I see it as a configuration setting in the UI that switches between behaviors (Jenkins, Jenkins+Otel, or Otel SemConv). I do not see that it needs an environment variable in Otel or any definition outside Jenkins because it is only for this plugin.