gardener: Merge green Dependabot pull requests every four hours

[scuffi]

Adds a dependabot-merge task. Every four hours, Gardener looks at open Dependabot pull requests:

• Green: it squash-merges the pull request.
  • Green means every check run at the head passed, was neutral or was skipped, at least one GitHub Actions check passed, and every commit status passed.
  • It merges at most 5 per run, oldest first.
• Failing: it comments once per head with which checks failed and what they report. It also says whether the same checks pass on main, so it's clear whether the update caused the failure. It doesn't try to fix anything.
• Changes under .github/, for example an Actions version bump: it never merges these. It comments once per pull request, asking a maintainer to review it.
• Conflicting for over a day: Dependabot normally rebases on its own. If it hasn't after a day, the task comments once so a maintainer can comment @dependabot rebase.
• Still running: it leaves the pull request for the next run.

How the task is scoped

• Dependabot only: it finds pull requests by searching for those authored by Dependabot, so other pull requests never reach it. It then confirms each one is open, not a draft, by dependabot[bot], on a dependabot/ branch in this repository, and into main.
• Untrusted text: it never reads pull request titles, bodies, commit messages or diffs. Bodies quote upstream release notes, and the task only needs file names. Anything else it reads is treated as data, not instructions.
• Exact checks: each merge lists every check run at the head, and Gardener re-checks them right before merging. If the pull request changed in the meantime, the merge is refused rather than merging unchecked code.
• Few permissions: it has no checkout and runs no commands. Its effects are pull_request.comment.create and pull_request.merge. A run proposes at most 5 merges and 10 comments.

What to expect

• Merges are made with the workflow token, so GitHub doesn't start CI on main for them. CI catches up on the next push by a person.
• Two Dependabot updates can conflict after one merges. That merge is then refused, and Dependabot rebases the other; a later run merges it.
• GitHub's scheduled runs can start late or be skipped when Actions is busy.
• A manual run is available from the Actions tab: "Gardener · Dependabot merge".

Tested on a demo repository first

• Merged: two green Dependabot updates were squash-merged.
• Failing update: it got one comment naming the failed check, and a fresh comment after Dependabot rebased it.
• Actions update: it got the maintainer comment and was not merged.
• While checks were still running: it waited.
• Repeat runs: no duplicate comments.

---

[changeset-bot]

⚠️ No Changeset found

Latest commit: f3b5c3b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[devin-ai-integration]

Note

Newer findings are available below. Devin Review posted a newer report on this PR, in addition to the findings presented here.

Devin Review found 3 potential issues.

[devin-ai-integration]

🔴 Green Dependabot updates remain unmerged

For a Dependabot update with only PR-triggered CI, check-runs on the head lacks a successful GitHub Actions run. CI tests the PR merge commit, so the ready gate never admits that update.

Learn more

The repository's CI runs on pull_request events, where GitHub Actions associates its runs with the pull request merge commit. The task instead reads check runs for the PR head SHA and requires one successful run from github-actions. Without another workflow that runs on the PR head, that condition remains false even after the PR's CI is green.

Example: Dependabot opens #300 at head abc; CI succeeds for the PR merge ref at xyz. The request for abc has no successful GitHub Actions run, and #300 is left out of the ready group despite green CI.

Recommended fix: Inspect checks associated with the PR merge commit used by CI, while binding the tested commit to the PR head and base SHAs and revalidating it at merge time.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@cloudflare/computer@208

commit: f3b5c3b

[devin-ai-integration]

Devin Review found 2 new potential issues.

[devin-ai-integration]

🔴 Stalled updates starve newer ready updates

With 15 older open updates stalled, dependabot-merge selects those same 15 on every run. A ready update behind them never gets examined or merged.

Learn more

The task searches open Dependabot pull requests, then inspects only the 15 oldest. A failed, waiting, conflicting, or manually reviewed pull request remains open. When 15 such requests occupy the first 15 positions, subsequent scheduled runs select them again and never reach later requests.

Example: Pull requests #1–#15 remain open with failing checks; #16 is green. Every four-hour run inspects #1–#15, so #16 stays unmerged indefinitely.

Recommended fix: Advance a durable cursor through ordered search pages, or exclude already-handled older requests from the next run without losing the ability to revisit them. Ensure the cursor wraps around and that stalled requests still get periodic rechecks.

---

Was this helpful? React with 👍 or 👎 to provide feedback.