datadog-ci junit upload for Test Visibility
datadog-ci junit upload ingests JUnit XML files into Datadog Test Visibility so test results, flakes, and durations are tracked over time.
Most test runners can emit JUnit XML. Uploading it to Datadog gives you flaky-test detection and trends without instrumenting the runner itself.
What it does
datadog-ci junit upload parses one or more JUnit XML files (or a directory) and sends each test case to Datadog, tagged with --service and the DD_ENV environment. It authenticates with DATADOG_API_KEY and routes by DATADOG_SITE.
Common usage
export DATADOG_API_KEY=...
export DATADOG_SITE=datadoghq.com
export DD_ENV=ci
datadog-ci junit upload --service web-app ./reports/junit/
# add custom tags
datadog-ci junit upload --service web-app \
--tags "team:frontend" --tags "git.branch:$BRANCH" ./junit.xmlOptions
| Flag / env | What it does |
|---|---|
| --service <name> | Service the tests belong to (required) |
| DD_ENV | Environment tag, e.g. ci |
| --tags "k:v" | Add custom tags (repeatable) |
| DATADOG_API_KEY | API key (required) |
| DATADOG_SITE | Datadog site |
| --dry-run | Parse and validate without uploading |
In CI
Run the upload even when tests fail (continue-on-error or a later step) so failed runs still appear in Test Visibility; otherwise you only ever see green builds. Set DD_ENV to ci and pass git tags so results are grouped by branch and commit.
Common errors in CI
"Missing API key. Please set DATADOG_API_KEY" means the secret is unset. "Cannot find any valid JUnit XML files" means the path is wrong or the runner did not emit XML. "403 Forbidden" means the key lacks the right scope or the DATADOG_SITE is wrong. Malformed XML reports as "could not parse" for that file and is skipped.