Some CI environments (e.g. Bitbucket Pipelines) only clone the current
branch by default, leaving the base branch ref unavailable locally.
This causes git merge-base to fail silently and patch coverage to be
missing from the uploaded event.

Explicitly fetch origin/<baseBranch> before computing the merge-base,
guarded in a try/catch so the fix degrades gracefully on fetch failure.

GitHub Actions and GitLab CI are unaffected — they supply a base SHA
directly and take the earlier code path. Azure/CircleCI/Jenkins hit
this path but already have all refs available, so the fetch is a no-op.

Bitbucket Pipelines merges the destination branch into the source at
build setup, so destination-branch commits are reachable in PR pipeline
history. However origin/<baseBranch> is absent as a remote-tracking
ref, causing git merge-base to fail silently and patch coverage to be
missing.

Rather than fetching the ref (previous approach, reverted), map
BITBUCKET_PR_DESTINATION_COMMIT to GIT_PULL_REQUEST_BASE_BRANCH_SHA in
the CI detection layer. datadog-ci then takes the direct baseSha code
path — same as GitHub Actions (pull_request.base.sha) and GitLab CI
(CI_MERGE_REQUEST_DIFF_BASE_SHA) — with no git operations needed.

Non-PR pipelines are unaffected: BITBUCKET_PR_DESTINATION_COMMIT is
only set in PR pipeline contexts, where patch coverage is meaningful.

…his PR)

…anch

fix(ci): map BITBUCKET_PR_DESTINATION_COMMIT to base branch SHA for patch coverage

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

….com

Add uk1.datadoghq.com as a supported Datadog site

…2388)

* feat(tag,measure): support additive comma-separated --level

Allow `--level pipeline,job` so the same tags/measures are applied to
multiple span levels in one invocation. Levels are deduped and validated
fail-fast; one request is sent per level. Adds a shared per-level loop
(`processLevels`) used by both `tag` and `measure`, and a per-execution
cache so the GitHub Actions diagnostic logs are located and read once
even when several levels need them (e.g. `--level job,step`).

Single-level usage and `--no-fail` semantics are unchanged: `--no-fail`
still tolerates a failed submission but not setup/config errors, which
are reported with the offending level.

Refs #2387

Co-Authored-By: Claude Opus 4.8 <[email protected]>

* fix(tag,measure): deterministically mock fs in fatal-level tests

These tests assumed the host filesystem lacks GitHub Worker_*.log
diagnostic files under the well-known fallback dirs to force the
`step` enrichment to fail. That assumption doesn't hold on real
GitHub Actions runners, causing flaky CI failures. Mock
fs.readdirSync to throw ENOENT explicitly instead.

* fix(tag,measure): drop multi-level support from measure, polish tag README

Reviewer feedback on #2388: measure semantics for multi-level are unclear
(should measures be aggregated/overwritten per level instead of duplicated?),
so revert measure back to single-level --level. tag keeps additive
comma-separated --level. Also applies 3 README wording nits for tag.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

* Clean up and remove technical details

---------

Co-authored-by: Claude Opus 4.8 <[email protected]>
Co-authored-by: Corentin Girard <[email protected]>

Let callers assign an explicit span ID and nest a custom span under another
custom span, instead of every span being flat under the job. --span-id
defaults to a generated ID when omitted; --parent-id references another
span's ID and attaches to the job/step as before when omitted. Both are
validated as hexadecimal.

This makes it possible to assemble arbitrary span trees (e.g. from an
OpenTelemetry dump) via repeated `trace span` calls.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

…id-parent-id

Add --span-id and --parent-id options to `trace span`

* docs(trace): surface the `trace span` subcommand

The `trace span` subcommand (report a standalone custom span with a name
and a duration or start/end time) ships and has its own README, but it was
not discoverable from the top-level command index: the `trace` section only
described the command-wrapping form and never mentioned or linked `span`.

- List `span` under the `trace` section in the root README, linking its README.
- Add a cross-reference from the `trace` README to the `trace span` subcommand.

Docs only; no behavior change.

Co-Authored-By: Claude Opus 4.8 <[email protected]>

* docs(span): make epoch timestamps explicit about UTC

`--start-time` / `--end-time` are epoch milliseconds, i.e. an absolute
UTC instant (serialized via `toISOString()`), but "unix epoch" alone can
read as ambiguous. Spell out UTC.

Co-Authored-By: Claude Opus 4.8 <[email protected]>

* Make front readme less verbose

---------

Co-authored-by: Claude Opus 4.8 <[email protected]>
Co-authored-by: Corentin Girard <[email protected]>