[ML] Auto-approve backport PRs so auto-merge can complete

[edsavage]

Summary

Backport PRs opened by the auto-backport workflow have auto-merge enabled but never merge (e.g. #3092). Two independent things blocked them:

1. No CI. buildkite-pr-bot only triggers ml-cpp-pr-builds for a PR whose sender is org-allowed: it matches an allowed_list entry, has admin/write on the repo, or is an org member (allow_org_users). Bot accounts are never org members and apps don't match the write-permission path, so a bot-authored backport got no build.
2. No approval. The release branches require one approving review via the org-wide ruleset [org] Require a PR (id 221255, source: elastic), which has no bypass actors. A PR authored by github-actions[bot] cannot be approved by github-actions[bot] (GitHub blocks self-approval), so the required review was never satisfied and auto-merge stayed BLOCKED.

The CI-trigger half (1) for github-actions[bot] is already fixed and validated by #3103 (allowed_list: ["github-actions[bot]"], #3099). This PR fixes the approval half (2) and completes the CI-trigger config for the ephemeral-token author.

What this PR changes

Adopts the production-proven author-with-ephemeral-token / approve-with-GITHUB_TOKEN pattern (used by elastic/cloud, elastic/elasticsearch-ruby and the ECP GitOps repos such as elastic/catalog-sync-config):

• backport.yml: mints a short-lived token from Elastic's central ephemeral-token service (elastic/ci-gh-actions/fetch-github-token@v1, ci-prod, via OIDC->Vault) before the backport action and passes it as the action's github_token, so the backport PRs are authored by the ephemeral-token identity (elastic-vault-github-plugin-prod[bot]) — a distinct identity from github-actions[bot]. It then approves each backport PR with GITHUB_TOKEN (github-actions[bot]) — a different identity from the author, so the approval counts — and enables auto-merge (squash). Adds id-token: write for OIDC.
• .buildkite/pull-requests.json: adds elastic-vault-github-plugin-prod[bot] to allowed_list, so buildkite-pr-bot triggers CI on the ephemeral-authored backport PRs. Combined with [ML] Allow github-actions[bot] to trigger ml-cpp-pr-builds CI #3103's github-actions[bot] entry, this matches elastic/elasticsearch's allow-list exactly (both bots).
• Safe no-op before the Token Policy is registered: the token fetch uses continue-on-error and the workflow falls back to authoring with GITHUB_TOKEN (github-actions[bot], which [ML] Allow github-actions[bot] to trigger ml-cpp-pr-builds CI #3103 already allow-lists for CI); auto-approval is skipped with a warning and the backport awaits a manual approval.

Why this counts (verified, not assumed)

elastic/catalog-sync-config merges renovate PRs under the identical org-only ruleset (221255 + 1225254; count: 1, require_code_owner_review: false, require_last_push_approval: false — same as ml-cpp): a PR authored by one bot and approved by github-actions[bot] (a non-author identity) shows reviewDecision: APPROVED and auto-merges (e.g. elastic/catalog-sync-config#83, elastic/catalog-info#4264). ml-cpp already has Allow GitHub Actions to create and approve pull requests enabled (can_approve_pull_request_reviews: true). GitHub's only relevant restriction is self-approval, which the author != approver split avoids.

The CI-trigger half was validated empirically: with #3103 live on main, a throwaway PR authored by github-actions[bot] auto-started ml-cpp-pr-builds (creator elasticmachine) within ~20s.

Required to activate (not in this repo)

Register the GitHub Token Policy in elastic/catalog-info (elastic/catalog-info#4281), scoped as:

• bound_claims.workflow_ref: elastic/ml-cpp/.github/workflows/backport.yml@*
• permissionset.additional_permissions: { contents: write, pull_requests: write } (contents to push the backport branch, pull_requests to open the PR), selector repository: elastic/ml-cpp
• owner: group:ml-core

Notes

• The earlier approach (approve with the ephemeral token) relied on an app holding only pull_requests: write being an eligible approver, which has no production precedent in the org. This pattern instead approves with GITHUB_TOKEN, which is proven to count.
• elastic/ci-gh-actions/fetch-github-token@v1 is used by tag; happy to pin to a SHA if org policy requires it.

Test plan

• Merge with the Token Policy unregistered -> a subsequent backport still opens the PR (authored by github-actions[bot]), gets CI (via [ML] Allow github-actions[bot] to trigger ml-cpp-pr-builds CI #3103), and arms auto-merge; logs the "ephemeral token unavailable" warning; does not fail.
• Register the Token Policy (#4281), trigger a backport, and confirm the PR is authored by elastic-vault-github-plugin-prod[bot], CI runs on it (via the new allowed_list entry), github-actions[bot] approves it, and it merges once checks pass.

Made with Cursor