Fix microbenchmarks crash caused by suspended GitHub App

[p-datadog]

What does this PR do?

Sets MANUAL_BASELINE_BRANCH before calling bp-runner in the microbenchmarks job, bypassing the github-find-merge-into-branch tool that crashes with a 403 error due to a suspended GitHub App installation (incident-51987).

Motivation:

All dd-trace-rb PRs that touch lib/, ext/, benchmarks/, datadog.gemspec, or .gitlab/ are currently failing microbenchmarks. The failure chain:

1. The microbenchmarks GitLab job runs bp-runner bp-runner.yml, which uses the shared run_microbenchmarks template from benchmarking-platform-tools.
2. Because dd-trace-rb's bp-runner.yml has parallelize:, the template uses a separate setup script (run-microbenchmarks__setup.sh).
3. During setup, github-find-merge-into-branch attempts to authenticate via a GitHub App installation to find the PR's target branch. That App is suspended:

   github.GithubException.GithubException: 403 {"message": "This installation has been suspended"}
   

4. The setup script exits non-zero. bp-runner catches this as NonZeroExitCodeError and fails the job.
5. With microbenchmarks failed, dd-gitlab/default-pipeline reports failure, and all-jobs-are-green fails on the GitHub side.

The shared template already has an escape hatch: if MANUAL_BASELINE_BRANCH is set, it skips github-find-merge-into-branch entirely. This PR sets that variable to the repo's default branch (detected from the clone's remote), which is master for dd-trace-rb.

Why this approach:

Other tracers already solved this at their own level rather than depending on the shared template:

• Go, Cpp, PHP: Call github-find-merge-into-branch with || : in their own custom run-benchmarks.sh scripts
• Python: Has a separate baseline:detect job using dd-octo-sts auth with || echo "main" fallback (in production since March 2025)
• Java: Hardcodes origin/master as baseline
• Dotnet: Downloads baseline from S3

dd-trace-rb is the only tracer still using the unguarded shared template. This one-line fix matches the resilience pattern every other tracer already has.

Why benchmarking-platform PR #254 didn't fix this:

benchmarking-platform PR #254 was merged as a workaround for incident-51987, but it only patched steps/post-pr-comment.sh (the PR commenting step). The actual failure is in github-find-merge-into-branch during the setup step — a different code path that uses the same suspended App.

Trade-off:

MANUAL_BASELINE_BRANCH is set to the repo's default branch (master), not the PR's actual target branch. For PRs targeting non-default branches, the baseline comparison would be against master instead of the actual target. This is the same trade-off Go/Cpp/PHP make, and for dd-trace-rb where ~100% of PRs target master, it's correct behavior.

Change log entry

None.

Additional Notes:

Verified affected pipelines:

• Pipeline 105468560 (PR [WIP] Before finish events #5535): microbenchmarks: [profiling] and [other] both failed with the 403 error
• Pipeline 105485812 (PR feat(telemetry): implement app-extended-heartbeat event #5531): Same failure
• Pipeline 105316901 (PR DI: Bypass subclass overrides of Exception#backtrace_locations via UnboundMethod #5521): Same failure

How to test the change?

Push a PR that touches lib/ or ext/ (to trigger the changes: rules for microbenchmarks) and verify the microbenchmarks jobs succeed. The bp-runner log should show MANUAL_BASELINE_BRANCH being used instead of calling github-find-merge-into-branch.

[p-datadog]

See also #5539 for a more robust alternative that detects the actual PR target branch via dd-octo-sts + gh CLI (modeled on dd-trace-py). This PR (#5538) is the simpler/faster fix; #5539 is the long-term solution.

[datadog-datadog-prod-us1]

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

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

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: d94d32a | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback!}