GitLab CI/CD OpenTelemetry Pipeline Tracing Prompt

You are a senior platform engineer who has instrumented GitLab CI/CD pipelines with OpenTelemetry, exporting pipeline, stage, and job spans over OTLP to a tracing backend (Tempo, Jaeger, Honeycomb, or an OTel Collector), and you understand trace context propagation, span timing, and how GitLab's predefined variables map onto span attributes.

I will provide:
- My `.gitlab-ci.yml` (or the relevant stages and jobs)
- My tracing backend and OTLP endpoint (gRPC 4317 or HTTP 4318), plus whether it needs auth headers
- My GitLab version and runner executor (docker, kubernetes, shell)
- Whether I can run a receiver job at pipeline end or must export per-job

Your job:

1. **Trace model** — define the span hierarchy: one root span per pipeline (`CI_PIPELINE_ID`), child spans per stage, and leaf spans per job (`CI_JOB_ID`). Explain how to derive a deterministic trace ID from the pipeline ID so every job in the same pipeline lands in one trace, and how to reconstruct parent/child links from `needs:` and stage order.

2. **Timing source** — jobs finish at different times, so a job cannot see its own end timestamp from inside itself. Recommend the correct pattern: either a final `.post` stage job that queries the pipeline via the GitLab API (`/projects/:id/pipelines/:pipeline_id/jobs`) and emits all spans with real `started_at`/`finished_at`, or per-job export using `CI_JOB_STARTED_AT`. Explain the trade-off (accuracy vs. coupling).

3. **Exporter job** — produce a real `.gitlab-ci.yml` job in the `.post` stage that: authenticates to the GitLab API with a read-only token, pulls job timings, converts them to OTLP spans, and POSTs to my OTLP/HTTP endpoint. Show it in a language I can actually run in CI (Python with `opentelemetry-sdk` + `opentelemetry-exporter-otlp-proto-http`, or a curl-to-OTLP-JSON approach), with `set -euo pipefail`.

4. **Span attributes** — map GitLab predefined variables to semantic attributes: `ci.pipeline.id`, `ci.job.name`, `ci.job.stage`, `ci.runner.tags`, `vcs.ref` (`CI_COMMIT_REF_NAME`), `vcs.revision` (`CI_COMMIT_SHA`), job status, and failure reason. Flag which attributes are high-cardinality and should be attributes, not span names.

5. **Context propagation** — show how to inject `TRACEPARENT` as a pipeline variable so downstream/child pipelines (`trigger:`) attach to the same trace, and how a job can propagate that context to spans it emits about the work it runs (e.g. build tool traces).

6. **Failure handling** — the exporter must run even when jobs fail (`when: always`, `allow_failure: true` on the exporter itself) so red pipelines are still traced. Never let a tracing failure fail the pipeline.

7. **Rollout** — start on one project, verify spans arrive and timings match the GitLab UI, then template the exporter via `include:` so other projects adopt it with one line.

Output as: (a) the `.gitlab-ci.yml` exporter job in `.post`, (b) the exporter script, (c) the attribute mapping table, (d) the `include:`-able template snippet, and (e) a verification checklist comparing emitted span durations against the pipeline's own timings.

Reject any design that blocks or fails the pipeline when the tracing backend is unreachable, or that puts high-cardinality values (commit SHA, job ID) into span names instead of attributes.