What must be true for a Dependabot patch bump to merge on GitHub without a human?

## Auto-merge is a GitHub feature, not a Dependabot one Dependabot opens a pull request like any other contributor. What lets that pull request land unattended is GitHub's auto-merge: a flag on the PR that says "merge this as soon as every requirement is green". Nothing about Dependabot bypasses branch protection — this is the tree's split in miniature. Git does the merge; GitHub decides the policy. ## The three preconditions **1. Repository setting.** *Allow auto-merge* is off by default and lives in repository settings. Without it, the option does not exist on any pull request. **2. Auto-merge enabled on the PR.** Someone or something must turn it on. Options: a human clicks it; a maintainer comments `@dependabot merge` (merge once checks pass) or `@dependabot squash and merge`; or automation enables it when the PR opens. Teams that want this to be systematic use the `dependabot/fetch-metadata` action to read the update type from the pull request and only enable auto-merge for patch or security bumps. **3. Branch protection must be satisfiable without a human.** This is the part candidates miss. Auto-merge waits for *all* merge requirements: - Required status checks — fine, they complete on their own. - Required conversation resolution — fine unless a bot or human comments. - Required linear history, signed commits, up-to-date-with-base — all satisfiable, though the last one causes repeated rebases and re-runs. - **Required reviews, especially required review from CODEOWNERS** — not satisfiable by CI. If your ruleset demands owner approval for the paths a manifest sits in, the PR sits open indefinitely. So "how do I auto-merge Dependabot PRs" is really "what does my protection rule require, and can a machine satisfy all of it". ## The Dependabot execution context Workflow runs triggered by Dependabot's own pull requests run with a **read-only `GITHUB_TOKEN`** and do **not** receive normal repository Actions secrets; they receive **Dependabot secrets**, which are a separate store. This is a deliberate hardening: a Dependabot PR carries third-party dependency code, and giving it a write token plus your secrets would be an obvious escalation path. The practical consequences: - Automation that enables auto-merge needs permissions the default read-only token does not have, so it must be granted explicitly or run from a context that has them. - Any workflow that needs a credential on Dependabot PRs must have it stored as a Dependabot secret, not an Actions secret. - Reaching for `pull_request_target` to get around the restriction is the classic dangerous fix: it runs with the base repository's permissions in the context of untrusted content. If you propose it in an interview, be ready to explain exactly what you would refuse to check out. ## Scoping what may auto-merge Even with the mechanism working, scope it. The defensible default is: patch-level bumps and security bumps within the current major, on repositories with a test suite you actually trust, where the full suite is a required check. Anything that merges without a human is only as safe as the gate in front of it — if your required checks are a lint job and a five-second smoke test, auto-merge is just an unattended `git push` with extra steps. The second half of the scoping decision is detection, not prevention. Auto-merge means changes reach the default branch while nobody is watching, so the compensating controls are the ones that catch a bad merge afterwards: deployment gates that a human still approves, staged rollout, and an alert that ties a production regression back to the merge window. Teams that auto-merge successfully are usually the ones whose deploy pipeline is good, not the ones whose dependency review is good. ## Keeping the PR mergeable A long-lived auto-merge PR can go stale — a required check flakes, or the base branch moves and the rule demands up-to-date branches. `@dependabot rebase` refreshes the branch; `@dependabot recreate` rebuilds it from scratch. If you use a merge queue on the base branch, auto-merge hands the pull request to the queue rather than merging directly, and the queue's own checks become the final gate. ## What to say in an interview Name the three preconditions, call out that a required CODEOWNERS review makes auto-merge impossible by design, mention the read-only `GITHUB_TOKEN` and separate Dependabot secrets, and finish with the scoping judgment: auto-merge is a bet on your required checks, so state what those checks are before you argue about which bumps qualify.