Leverage the sh/bat steps with the system that interact with

[jenkinsci]

Leverage the sh/bat steps with the system that interact with

[cyrille-leclerc]

I'm wondering if we should introduce some Jenkins pipeline steps to expose io.opentelemetry.api.trace.Span#updateName(newName) and io.opentelemetry.api.trace.Span#setAttribute(key, value).
@v1v would this solve your problem?

[cyrille-leclerc]

The first improvement could be to use the label attribute of the shell steps (sh...) as span name: https://www.jenkins.io/doc/pipeline/steps/workflow-durable-task-step/#sh-shell-script

[v1v]

I'm wondering if we should introduce some Jenkins pipeline steps to expose io.opentelemetry.api.trace.Span#updateName(newName) and io.opentelemetry.api.trace.Span#setAttribute(key, value).
@v1v would this solve your problem?

Do you mean something like the below snippet?

pipeline {
  ...
          ...
          spanService(name: 'my.docker.registry') {
            sh 'docker login -u $user -p $pass $OTEL_STEP_SERVICE'
          }
          ...
}

If so, will it be possible to populate the parent span attributes to the child sh span?

[cyrille-leclerc]

For this shell step, i was thinking of using the label attribute of the sh step (label: docker/login my.docker.registry). The limit in my rationale is that I can just set the span name and not inject span attributes like jenkins.pipeline.step.type: docker/login.

⚠️ Note that I'm not sure that my idea of just changing the span name is a good idea. The best could be to use the Semantic conventions for RPC spans with a span name docker/login and attributes net.peer.name: my.docker.registry, rpc.service: docker, rpc.method: login, rpc.system: http. Following the https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/rpc.md) would require a wrapping step similar to what you suggested.

pipeline {
          ...
          withCredentials([usernamePassword(
               credentialsId: 'dockerCredentials', 
               usernameVariable: 'USERNAME', 
               passwordVariable: 'PASSWORD')]) {

          sh (label: 'docker/login my.docker.registry', script: 'docker login -u $USERNAME -p $PASSWORD")
          ...
}

[v1v]

I've been thinking about this particular feature and came up with the below idea.

People can opt-in if the step they call supports the apm attributes, therefore we could allow people to use a new key in their call. This will only work for steps that don't have an argument validation.

Unfortunately, the step itself should provide the DataBoundSetter for the apm argument:

pipeline {
  ...
          ...
          theStep(..., apm: [ 'net.peer.name': 'my.docker.registry', 'rpc.service': 'docker', 'rpc.method': 'login', 'rpc.system': 'http']
          ...
}

If we like the above, we could even move forward and enhance the built-in steps to support the above, though we might need to raise a JEP to request such a functionality in the Jenkins Core and the Pipeline plugins, since there is a signature validation and unexisting parameters are not allowed (WorkflowScript: 8: Invalid parameter "apm", did you mean "label"?)

To illustrate the above:

pipeline {
  ...
          ...
          sh(label: 'docker login', script: 'docker login -u $user -p $pass $OTEL_STEP_SERVICE', apm: [ 'net.peer.name': 'my.docker.registry', 'rpc.service': 'docker', 'rpc.method': 'login', 'rpc.system': 'http'])
          ...
}

Why do I like this approach?

1. Development experience, there will be always a new argument to leverage the existing attributes when using the plugin.
2. Distributed traces to be a first citizen and supported by the Jenkins core (or workflows) by default.

In order to test the above I did raise the below changes:

1. In the plugin itself -> #64
2. In the durable task plugin -> v1v/workflow-durable-task-step-plugin@adc9afa or v1v/workflow-durable-task-step-plugin@2e8683f if it consumes the OtelStep class

Tests:

node() {
    echo 'Hello World'
    sh(script: 'echo hi',  apm: [ 'net.peer.name': 'my.docker.registry', 'rpc.service': 'docker', 'rpc.method': 'login', 'rpc.system': 'http'])
}

Produced the below log traces

Apr 10, 2021 1:33:02 PM INFO io.jenkins.plugins.opentelemetry.job.CommonStepHandler createSpanBuilderFromApmDetails
Create apm {net.peer.name=my.docker.registry, rpc.service=docker, rpc.method=login, rpc.system=http}

And the span attributes are properly added:

What do you think?

[cyrille-leclerc]

Close: we recommend to use the sh(label='xxx',...) and the otel-cli to add context