Continuously integrate libdatadog via scheduled job

[bwoebi]

Adding a pipeline which will be called on master with SCHEDULED_LIBDATADOG_LATEST=true variable every night.

This makes sure that we get early / quick insights when a change on libdatadog breaks the dd-trace-php build:

• Run the master branch CI with the latest main commit of libdatadog
• Pull all pipeline failures
• Retry them to avoid flakiness polluting claudes work
• Have claude analyze the remaining failures (with focus on compile fails, then everything else)
• Create a PR with the changes
• CI will naturally run again on that PR (it's a new branch, so...)
• Claude will verify the results of that pipeline too (i.e. verify its own fixes, possibly fixing secondary issues after initial compilation failure results) and push additional fixes as needed
• A human looks at the PR and merges / decides on further action.

It works, see https://gitlab.ddbuild.io/DataDog/apm-reliability/dd-trace-php/-/jobs/1629546146. Also see the attached artifact, which claude generated on that pipeline:

# libdatadog Integration Report

**libdatadog SHA**: 243aec1b5450b7edb546b5a59e5f80ab79abed08
**Analysis date**: 2026-04-24

## Overall status

✅ Clean update

## Build & test summary

CI ran across appsec, tracer, profiler, shared, and package
sub-pipelines. One job failed:

- `[appsec-trigger] check libxml2 version` — marked `allow_failure:
  true` in the pipeline configuration, so it is non-blocking.

No Rust compilation traces were produced (the `artifacts/traces/`
directory is empty), confirming that all Rust/C build steps succeeded.

## Non-trivial changes made

No code changes required.

The five commits in this update do not alter any public FFI surface
used by dd-trace-php:

| Commit | Description | Impact on dd-trace-php |
|--------|-------------|------------------------|
| `243aec1b5` | fix(libdd-common): fix `--all-features` build condition | Build/test only; no API change |
| `6b026965d` | fix(sidecar)!: Prefer session-id for remote config | Internal sidecar server change; FFI unchanged (see below) |
| `cf8c1cfa0` | build(profiling): rustc-hash 2.1.2 | Dependency version bump; no API change |
| `950562bb1` | ci: fix unbound variable | CI script fix; no code change |
| `27aa92cfe` | feat(libdd-trace-utils): reject empty `datadog-client-computed-stats` header value | Backward-compatible behaviour fix; dd-trace-php already sends a non-empty value when the flag is true |

### Detail: `fix(sidecar)!` — internal server change

The `!` (breaking) marker applies to libdatadog's own internal API.
The change removes the `instance_id` parameter from
`RuntimeInfo::update_remote_config` in
`datadog-sidecar/src/service/runtime_info.rs` and routes remote-config
subscriptions via `session_id` instead of `instance_id.runtime_id`.
This is purely server-side routing logic inside the sidecar process.

The public C FFI functions that dd-trace-php calls —
`ddog_sidecar_instanceId_build`, `ddog_sidecar_session_set_config`, and
all remote-config reader/writer functions — are **unchanged**. No
call sites in `components-rs/`, `appsec/helper-rust/`, or other
dd-trace-php Rust crates need to be updated.

## Identified libdatadog issues

None identified.

## Flaky / ignored failures

- `[appsec-trigger] check libxml2 version` — checks that the host
  system's libxml2 meets a minimum version requirement. This is an
  environment/infrastructure constraint unrelated to the libdatadog
  changes in this update, and is already marked `allow_failure: true`
  in the pipeline.

The octo sts token permissions are still missing on master, so can't test pushing yet, but at least it gets right up to that point.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1a99a44fe5

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[datadog-datadog-prod-us1]

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 60.64% (-0.04%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 77cab62 | Docs | Datadog PR Page | Give us feedback!}

[pr-commenter]

Benchmarks [ tracer ]

Benchmark execution time: 2026-04-24 19:41:10

Comparing candidate commit 77cab62 in PR branch bob/libdatadog-ci with baseline commit 4feb951 in branch master.

Found 2 performance improvements and 0 performance regressions! Performance is the same for 191 metrics, 1 unstable metrics.

scenario:ComposerTelemetryBench/benchTelemetryParsing-opcache

• 🟩 execution_time [-1.810µs; -0.790µs] or [-10.775%; -4.701%]

scenario:MessagePackSerializationBench/benchMessagePackSerialization-opcache

• 🟩 execution_time [-6.915µs; -4.825µs] or [-6.099%; -4.255%]

[Leiyks]

Suggested change

	dd-octo-sts token --scope DataDog/dd-trace-php --policy gitlab-ci-libdatadog-latest > tmp/github_token.txt
	GITHUB_TOKEN=$(cat tmp/github_token.txt)
	export GITHUB_TOKEN GH_TOKEN="${GITHUB_TOKEN}"
	GITHUB_TOKEN=$(dd-octo-sts token --scope DataDog/dd-trace-php --policy gitlab-ci-libdatadog-latest)
	export GITHUB_TOKEN GH_TOKEN="${GITHUB_TOKEN}"

We may want to avoid having to write token to disk just in case

[Leiyks]

Suggested change

	after_script:
	- if [[ -f tmp/github_token.txt ]]; then dd-octo-sts revoke -t "$(cat tmp/github_token.txt)" || true; fi

Not needed if we don't write token to disk

[Leiyks]

should we restrict accessible directories to ensure Claude is not messing with files other than libdatadog / dd-trace-php ?