dependabot-auto-merge: retry arming, fall back to a direct merge

[lucas-d-ramos]

Prerequisite for converging the last four auto-merge holdouts onto the reusable.

Why these four never adopted it

wemove.eu, youmove, wemove-charity.eu and pubstatic each carry an inline copy of
the auto-merge job. The reason is in their own comment — the inline version does
something the reusable did not:

# `gh pr merge --auto` occasionally hits a transient GitHub GraphQL error,
# which used to strand the PR. Retry a few times; and fall back to a direct
# squash merge in case the required checks already went green (auto-merge
# can't be enabled on an already-clean PR).

Two distinct failure modes, both real:

1. Transient GraphQL error from gh pr merge --auto — the PR is left
   unarmed and nobody finds out until someone looks.
2. Already-green PRs cannot have auto-merge enabled at all. With fast CI the
   checks frequently win the race against this workflow, and the PR then sits
   green and unmerged indefinitely.

Migrating them to the reusable as it stood would have silently dropped both
protections. Porting the logic here instead lets all four drop ~20 lines and
converge.

Is the fallback a bypass?

No. Branch protection refuses a direct merge while required checks are pending or
failing — the fallback only succeeds where auto-merge was impossible because the
checks already passed.

On a repo with no required checks it would merge immediately. That is not new
(the same is true of --auto there) and it is why a ruleset is part of the entry
bar for using this workflow at all.

Also

merge-method now reaches the script through env: rather than ${{ }}
interpolation into the run body, so a caller cannot inject shell through it.

Release

Behaviour change, additive → v14.2.0, floating v14 moves. Existing callers
get the retry with no action.

🤖 Generated with Claude Code