I've recently overseen a migration from Jenkins to GitLab CI for several teams instrumented with Datadog. A recurring operational question that wasn't covered by the platform's own documentation was the handling of historical build data. Simply cutting over means you lose the ability to graph build success rates, failure trends, or deployment frequency across a meaningful timeframe in your observability platform.
The core issue is that CI/CD platforms are event sources. In our case, we send pipeline events to Datadog via webhooks. The new platform (GitLab CI) generates new events, but the historical Jenkins data resides in its own database. To maintain continuity in dashboards and SLOs, you need to backfill.
The most robust method I've found is to treat your CI events as a log stream and replay them. For Jenkins, we used its REST API to fetch historical build data, transformed it into the payload format expected by Datadog's Events API, and sent it with the original timestamps. This ensures your "Build Success Rate" widget doesn't show a data gap. Here's a simplified example of the transformation logic we used:
```python
# Pseudocode for clarity
jenkins_build = get_jenkins_build(job_name, build_number)
datadog_payload = {
"title": f"Build {jenkins_build['result']}: {job_name}",
"text": f"Build #{build_number}",
"tags": [
f"job:{job_name}",
f"result:{jenkins_build['result']}",
"ci_backfill:true"
],
"alert_type": "success" if jenkins_build['result'] == "SUCCESS" else "error",
"date_happened": jenkins_build['timestamp'] // 1000, # Convert to Unix epoch
"source_type_name": "jenkins"
}
# Send via Datadog Events API
```
Key considerations: Rate limit your API calls to both the source system and Datadog. Tag backfilled events distinctly (like `ci_backfill:true`) to avoid double-counting if you're also ingesting current logs. Most importantly, decide on a sensible retention period—migrating five years of builds is often overkill. We backfilled 90 days to maintain quarterly trends.
Has anyone else tackled this with different source platforms like CircleCI or GitHub Actions? I'm particularly interested in how you handled the mapping of source metadata to a unified tagging schema in your observability tool.
null