OpenTelemetry traces for tasks

[lwencel-priv]

Related with PR: #2933

Description

Add optional OpenTelemetry tracing to Task so users can observe the execution of Taskfile tasks and commands in an OpenTelemetry-compatible backend such as Jaeger.

When tracing is enabled, Task should create a trace that represents the execution hierarchy, including:

• top-level and nested task executions;
• task-to-task calls and shell commands;
• parent/child relationships between those operations;
• execution duration;
• whether an operation was executed, skipped, or failed;
• errors and useful, non-sensitive execution metadata.

The feature should be opt-in and configurable through standard OpenTelemetry environment variables. Normal Task behavior should remain unchanged when no trace exporter is configured.

This request is specifically for tracing task and command execution. It does not require Task to expose Prometheus metrics or add general-purpose logging/metrics support. The exporter and dependency scope should be discussed, as the initial implementation's automatic exporter support introduces a substantial transitive dependency set, including Prometheus-related packages.

Problem this would solve

Task is often used to orchestrate CI/CD workflows containing nested tasks and multiple shell commands. Existing CI logs can show output and failures, but they do not provide a structured timing and dependency view of the workflow at the Taskfile level.

This makes it difficult to:

• measure the duration of individual tasks and commands;
• see which operations ran sequentially or as nested work;
• compare traces across pipeline runs and identify performance regressions or trends;
• find the task or command at which a pipeline failed;
• distinguish executed work from work skipped because of platform filters, if conditions, up-to-date checks, or dry-run behavior;
• correlate Task execution with the rest of an organization's observability data.

The intended use case is faster CI/CD performance analysis and incident diagnosis. Instead of treating the whole Task invocation as one opaque CI step, users could inspect its internal task/command hierarchy and timings in their existing telemetry platform.

Im using taskfile to run multiple ci/cd processes on different platforms - Jenkins, GitHub Actions, locally. Tracing will help to track entire build/test infrastructure in one place and check places which can be optimized to reduce execution time.

Example usage

For example, a CI job could configure Task to export traces to an OpenTelemetry collector or directly to Jaeger-compatible infrastructure:

export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_TRACES_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_COMPRESSION=gzip
export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=https://<otel-endpoint>/v1/traces
export OTEL_SERVICE_NAME=taskfile-ci

# Only when required for a private/self-signed CA setup:
export OTEL_EXPORTER_OTLP_CERTIFICATE=/etc/ssl/certs/ca-certificates.crt

task default

The resulting trace could show a hierarchy similar to:

default
├── task:lint
│   └── shell: golangci-lint run
└── task:test
    ├── task:gotestsum:install
    │   └── shell: go install gotest.tools/gotestsum@latest
    └── shell: gotestsum -f pkgname ./...

Example scenarios:

1. Find a CI regression: compare recent traces with earlier runs and identify that test or a tool-install task accounts for the increased pipeline duration.
2. Diagnose a failure: locate the failed task/command span, inspect its error status, and see the operations that led to it.
3. Understand skipped work: determine that a task or command was skipped because of an if condition, platform restriction, up-to-date status, or dry run.
4. Use an existing observability stack: export Task traces via OTLP and view them alongside traces from other build and deployment services.

For local evaluation or debugging, a console/stdout trace exporter could also be supported if this can be done without an excessive dependency cost.

Expected behavior and scope

• Tracing is disabled by default and has negligible impact when not configured.
• Enabling tracing does not alter task ordering, concurrency, output, exit codes, or failure behavior.
• Trace context is propagated through nested task and command execution so the trace reflects the real execution hierarchy.
• Failed operations record an error and error status.
• Executed and skipped operations have explicit outcomes; skip reasons are recorded where available.
• The tracer provider is flushed and shut down cleanly before Task exits.
• Documentation includes setup, at least one OTLP example, default-disabled behavior, and a description of emitted attributes.