Learn how the Gitlab Duo Agent Platform helped me design and ship a complete GitLab CI pipeline: emitting OTel traces and integrating with Argo, in just one hour before my KubeCon talk.
Building a live demo for a conference can feel overwhelming. A few weeks ago, I committed myself to building an entire end-to-end CI/CD observability demo for my talk at KubeCon using Argo Workflows, Argo CD, and OpenTelemetry. But as anyone who has built live demos knows, things rarely stay simple. Between trace propagation, pipeline wiring, and environment setup, the list of moving pieces grows fast.
And then came the curveball. The original demo only included Argo Workflows and ArgoCD, with no CI component at all, and just one hour before my talk, my co-presenter and I decided that GitLab CI needed to be part of the story. That meant creating a pipeline, instrumenting it with OTel, wiring it to Argo, and exporting everything to SigNoz. Thankfully, I also had a secret superpower: the GitLab Duo Agent Platform. It became the key to building a fully functioning CI demo in record time.
Setting the Scene - What we wanted to show in our talk
While production observability is mature, visibility into the CI/CD journey before code reaches production is often missing. Thus, I and my co-presenter were presenting a KubeCon talk focused on end-to-end CI/CD observability using OpenTelemetry. In the session, we introduced CI/CD observability using OTel, with a deep dive into Argo Workflows and ArgoCD, showing how a single code change moves through GitLab CI, Argo Workflows, and Argo CD, all stitched together using OpenTelemetry’s new CI/CD semantic conventions.
Our goal was to highlight how the latest OTel CI/CD Semantic Conventions provide a vendor-neutral way to instrument every stage of the delivery pipeline, that is from build to deployment, thus making CI/CD telemetry just as accessible and standardized as application telemetry. We covered how to emit traces and metrics from Argo Workflows and ArgoCD, and how OTel can surface critical signals like job duration, workflow execution latency, deployment failures, and promotion events.
The original demo only covered ArgoCD, with no CI component at all. But just an hour before our presentation, during a quick conversation with my co-presenter, we realized that the story would be incomplete without showing how GitLab CI fits into the end-to-end trace flow.
GitLab Duo Agent Platform saves the day
To keep the talk impactful, we needed a fully working end-to-end demo: a commit triggering GitLab CI, emitting spans from each stage, launching an Argo Workflow for integration testing, handing off to ArgoCD for deployment, and finally showing a single trace in our SigNoz dashboard. Doing this manually would not have been possible in 1 hour, but with the Gitlab Duo Agent Platform we were able to generate the GitLab CI integration complete with OTel spans, otel-cli setup, trace propagation, and Argo Workflow submission in under an hour. That last-minute addition ended up becoming the highlight of our session.
To extend the talk demo to include CI, I needed GitLab CI to become part of the same end-to-end trace that already included Argo Workflows and Argo CD. So I asked Duo to help me generate the missing CI integration. Here’s the exact prompt I used:
I already have my OTel demo working for Argo Workflows and Argo CD using OTEL CLI. Now I also want to integrate the CI layer using GitLab CI.
Use a GitLab Runner to emit OTel spans via OTEL_EXPORTER_OTLP_ENDPOINT.
Wrap the key GitLab stages: build, test, package, using OpenTelemetry SDK calls so each step appears as a span.
Export all CI traces to SigNoz (OTLP endpoint).
Finally, show how the GitLab job (build) can trigger an Argo Workflow (integration test) which then leads to an Argo CD deployment — all stitched together through trace context propagation.
The final output should create one seamless story:
Commit → GitLab CI → Argo Workflow → Argo CD → Deployment → Observability Dashboard.”*
This became the starting point for the GitLab CI configuration that powered my KubeCon demo. Using the DAP agent I generated a .gitlab-ci.yml in minutes. The resulting pipeline includes four stages, each emitting its own OpenTelemetry span to trace the CI/CD execution. Every job installs otel-cli and creates a span that represents that stage of the pipeline (build, test, or package). In the integration stage, the pipeline installs the Argo CLI and automatically submits an Argo Workflow. This allowed the GitLab CI trace to seamlessly connect with the downstream Argo Workflow execution, creating a unified, end-to-end observability story.
Demo
You can check the live demo of the CI pipeline here:
And you find the code for the CI/CD pipeline here: https://gitlab.com/shivaylamba/kubecongitlabdemo
Final Thoughts
With just a few prompts and light debugging, the Duo Agent Platform helped me build the entire GitLab CI flow for the KubeCon demo in just about an hour, something that would normally take much longer. But the capabilities of Duo Agent Platform doesn’t end at helping create your code, you can also use the Duo Agent Platform with your GitLab CI environment to debug runners, optimize jobs, reason about logs, fix pipeline failures, and even explain complex YAML configurations.
Top comments (0)