ci: drive Devflow from GitHub merge queue

[rochdev]

What does this PR do?

Adds the supported bridge between GitHub's native merge queue and the Datadog
Devflow merge queue.

When a contributor clicks Merge when ready, the flow is:

1. GitHub emits the pull request enqueued event.
2. A pull_request_target workflow loaded from protected main obtains a
   narrowly scoped Octo STS GitHub App token.
3. The app posts /merge on the pull request.
4. The merge_group check deliberately fails, preventing GitHub from merging
   the pull request itself.
5. Devflow performs its existing validation, queueing, and merge process.

Motivation

The current repository configuration disables the normal merge control for
contributors, requiring them to know and post the /merge command manually.
This provides GitHub's standard Merge when ready experience without
allowing GitHub to bypass the custom Devflow queue.

The implementation follows the existing dd-trace-java integration documented
in the internal "GitHub Merge Queue 💜 Datadog Merge Queue" guide.

Additional Notes

The actionlint wrapper is updated from 0.1.9 to 0.1.12. The former bundles
actionlint 1.7.7, whose event schema predates GitHub's supported
pull_request_target: enqueued activity; 0.1.12 bundles actionlint 1.7.12.

Steps to enable after this PR lands

These repository settings are intentionally not changed by this PR. A repository
administrator should:

1. Land this PR using the existing /merge flow.
2. Open Settings → Rules → Rulesets for DataDog/libdatadog.
3. Add a branch ruleset targeting the default branch.
4. Enable Require merge queue.
5. Set Minimum group size to 1, so the bridge runs immediately.
6. Add Merge queue check as a required status check.
7. Leave repository auto-merge disabled. The supported entry point is GitHub's
   native merge queue and its Merge when ready button.

Compatibility with existing open pull requests

Enabling the ruleset does not trigger this workflow for pull requests that were
already open. Their current head commits may therefore lack Merge queue
check and will not be able to use Merge when ready immediately.

Those pull requests can continue using the existing /merge command; Devflow's
merge app uses its established ruleset bypass path. No mass backfill or reopening
is required. An existing pull request will gain the new check naturally after
its branch is updated or the pull request is reopened, after which it can use
Merge when ready as well.

The failure on merge_group is intentional: it removes the pull request from
GitHub's queue before Devflow takes ownership. Existing devflow/mergegate
rules and repository.datadog.yml remain unchanged.

How to test the change?

• SHELLCHECK_OPTS='-e SC2086' actionlint
• Parse both new files as YAML.
• After enabling the ruleset, use a test PR to confirm that Merge when ready
  produces an Octo STS /merge comment and queues the PR in Devflow.

Generated by Codex.

[datadog-prod-us1-3]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 76.56% (-0.03%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: af93076 | Docs | View more details | Give us feedback!}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 27939272d2

ℹ️ 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".

[ekump]

You can just use the doggo extension for the MQ button and there are better ways to enforce the MQ on the repo than adding the extra complexity of GH's queue.

[dd-octo-sts]

Artifact Size Benchmark Report

aarch64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a	89.52 MB	89.52 MB	0% (0 B) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so	8.26 MB	8.26 MB	0% (0 B) 👌

aarch64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so	11.06 MB	11.06 MB	0% (0 B) 👌
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a	100.70 MB	100.70 MB	0% (0 B) 👌

libdatadog-x64-windows

Artifact	Baseline	Commit	Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll	26.64 MB	26.64 MB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib	94.96 KB	94.96 KB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb	180.73 MB	180.74 MB	+0% (+8.00 KB) 👌
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib	772.85 MB	772.85 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll	8.73 MB	8.73 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib	94.96 KB	94.96 KB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb	25.65 MB	25.65 MB	0% (0 B) 👌
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib	51.09 MB	51.09 MB	0% (0 B) 👌

libdatadog-x86-windows

Artifact	Baseline	Commit	Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll	23.22 MB	23.22 MB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib	96.45 KB	96.45 KB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb	185.66 MB	185.68 MB	+0% (+16.00 KB) 👌
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib	759.09 MB	759.09 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll	6.74 MB	6.74 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib	96.45 KB	96.45 KB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb	27.59 MB	27.59 MB	0% (0 B) 👌
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib	48.62 MB	48.62 MB	0% (0 B) 👌

x86_64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a	79.78 MB	79.78 MB	0% (0 B) 👌
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so	9.16 MB	9.16 MB	0% (0 B) 👌

x86_64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a	95.42 MB	95.42 MB	0% (0 B) 👌
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so	11.17 MB	11.17 MB	0% (0 B) 👌

[rochdev]

You can just use the doggo extension for the MQ button and there are better ways to enforce the MQ on the repo than adding the extra complexity of GH's queue.

Using the built-in feature that doesn't require an extension is better than reinventing the wheel and makes the experience better for everyone.

[pr-commenter]

Benchmarks

Comparison

Benchmark execution time: 2026-08-25 13:18:56

Comparing candidate commit af93076 in PR branch rochdev/enforce-datadog-merge-queue with baseline commit a25619e in branch main.

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

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

• 🟩 = significantly better candidate vs. baseline
• 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:otlp/e2e_json/1x1000

• 🟥 execution_time [+258.536µs; +260.995µs] or [+6.224%; +6.283%]

scenario:otlp/encode_json/1x1000

• 🟥 execution_time [+317.049µs; +318.768µs] or [+17.558%; +17.653%]

Benchmark execution time: 2026-08-25 13:25:27

Comparing candidate commit af93076 in PR branch rochdev/enforce-datadog-merge-queue with baseline commit a25619e in branch main.

Found 3 performance improvements and 4 performance regressions! Performance is the same for 161 metrics, 10 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

• 🟩 = significantly better candidate vs. baseline
• 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:alloc_free/system/4096

• 🟥 execution_time [+12.545ns; +12.768ns] or [+13.432%; +13.670%]

scenario:datadog_sample_span/parent_not_sampled_short_circuit/wall_time

• 🟩 execution_time [-0.404ns; -0.399ns] or [-4.368%; -4.316%]

scenario:datadog_sample_span/parent_sampled_short_circuit/wall_time

• 🟩 execution_time [-0.404ns; -0.398ns] or [-4.368%; -4.305%]

scenario:glob_matcher/unicode_exact_match/wall_time

• 🟥 execution_time [+2.978ns; +3.025ns] or [+4.054%; +4.117%]

scenario:glob_matcher/unicode_pattern_wildcard_match/wall_time

• 🟥 execution_time [+6.980ns; +7.123ns] or [+5.595%; +5.709%]

scenario:no_profiler/short_circuit/4096

• 🟥 execution_time [+8.970ns; +9.104ns] or [+9.385%; +9.525%]

scenario:profiler_attached/fast_path_system/4096

• 🟩 execution_time [-5.414ns; -5.284ns] or [-5.513%; -5.381%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

[bwoebi]

@ekump I'd definitely prefer this over the doggo or /merge commands.