Dependabot Merge

Dependabot Merge

Merge safe dependency updates. Stop and report the unsafe ones. Never merge a pull request that you did not check in this run.

Use the gh-cli skill for queries, required-check watching, and failure logs. In a batch, process other ready pull requests instead of waiting on one.

The checks are the same for every dependency bot. Only the discovery query and the place that holds the update metadata change. See "Which bots".

Scope

The scope is fixed: the goreleaser organization and the caarlos0 user. Do not ask which owners to process. Start the run immediately.

Never widen the scope on your own. The user belongs to many organizations that they do not maintain. Merging there affects other people. Process another owner only when the user names it in the argument, and process only that owner in addition to the two above.

Ledger

Keep a ledger, so that a second run does not check the same pull request again. Create it once per run with the sql tool:

CREATE TABLE IF NOT EXISTS dependabot_prs (
  url TEXT PRIMARY KEY,
  repo TEXT, number INTEGER, title TEXT,
  bot TEXT,       -- dependabot | renovate | pre-commit-ci | ...
  state TEXT,     -- pending | merged | skipped | blocked | failed
  reason TEXT,
  checked_at TEXT
);

Write a row with state='pending' when you find a pull request. Update the row immediately after each decision. Read the ledger before each step and process only pending rows. Report the terminal rows again at the end, but do not check them again.

Which bots

Handle every dependency bot, not only Dependabot. They differ in three ways: the author login, where the update metadata lives, and the branch prefix.

Renovate has no commit metadata block. Its versions live in a markdown table in the pull request body, next to a <!--renovate-debug:...--> comment:

gh pr view NUMBER -R REPO --json body -q .body

That table is generated at the same time as the diff, but it is still a summary. The rule below does not change: read the diff.

Two Renovate-only things to watch:

• A pull request that edits renovate.json, .github/renovate.json or .renovate.json is a configuration change, not a dependency bump. It is outside the manifest/lockfile/workflow allowlist, so it is blocked for a human.
• Renovate can run postUpgradeTasks and custom managers, so it can touch files a version bump does not explain. Treat any such file as a block.

Collect

gh search prs takes only one --author, and a second flag silently replaces the first. Use the search API instead, where a repeated author: qualifier means OR.

Run one query for each owner. org: covers an organization and user: covers a personal account; they are not interchangeable, and a separate query keeps the 100-item page limit and any error for each owner separate. These are the discovery commands for this skill — run them as-is:

BOTS='is:pr is:open draft:false author:app/dependabot author:app/renovate author:app/pre-commit-ci'

gh api -X GET search/issues -f per_page=100 \
  -f q="org:goreleaser $BOTS" \
  --jq '.items[] | "\(.user.login)\t\(.html_url)\t\(.title)"'

gh api -X GET search/issues -f per_page=100 \
  -f q="user:caarlos0 $BOTS" \
  --jq '.items[] | "\(.user.login)\t\(.html_url)\t\(.title)"'

Collect both into urls.txt for the parallel fetch below:

for owner in org:goreleaser user:caarlos0; do
  gh api -X GET search/issues -f per_page=100 \
    -f q="$owner $BOTS" --jq '.items[].html_url'
done > urls.txt

Each query returns at most 100 items for each page. Compare the line count with total_count and paginate with -f page=2 when it is larger.

Keep the q value on one line. A newline inside it makes the search API reject the whole query with 422 Validation Failed.

Add a self-hosted bot with a plain author:renovate-bot (no app/ prefix, because it is a normal account).

Do not trust is_bot. In gh search prs output, dependabot[bot] reports is_bot: false. Match on the login instead.

Insert the results into the ledger, recording which bot opened each one.

Use single quotes for every SQL string. SQLite rejects a double-quoted literal that does not name a column, and the whole insert fails.

Fetch the facts for all of them in parallel, then triage from one table instead of one round trip per pull request. Write the worker to a file: on macOS, xargs -I combined with -n 1 and a long inline sh -c fails with command line cannot be assembled, too long.

cat > fetch.sh <<'EOF'
#!/bin/sh
gh pr view "$1" --json number,url,author,isDraft,mergeable,mergeStateStatus,\
files,commits,statusCheckRollup > "out/$(echo "$1" | tr '/:' '__').json" 2>&1
EOF
chmod +x fetch.sh
xargs -P 8 -I{} ./fetch.sh {} < urls.txt

Check each pull request

Get the facts in one call:

gh pr view URL --json number,author,isDraft,mergeable,mergeStateStatus,\
reviewDecision,files,commits,statusCheckRollup

The commit body holds the metadata in the updated-dependencies: block: dependency-name, dependency-version, dependency-type, and update-type. A grouped update lists many entries. Check every entry. Renovate puts the same information in the pull request body instead — see "Which bots".

The metadata can disagree with the diff. The diff wins. The bot rebases and the summary goes stale. One pull request declared dependency-version: 5.24.0 and update-type: version-update:semver-minor while gh pr diff showed 5.22.0 to 6.0.0. Another declared dependency-version: 10.0.1 while the workflow comment still read # v6.6.1 and the real old pin was v8.2.0 — three different answers, and only the diff was right. Read the diff before you call a bump minor:

gh pr diff NUMBER -R REPO -- package.json go.mod

For a pinned action, the comment after the SHA is decoration and can be stale. Resolve the SHA itself:

gh api repos/OWNER/REPO/tags --paginate \
  --jq '.[] | select(.commit.sha=="NEWSHA") | .name'

Set state='blocked' and continue to the next pull request if any of these is true:

• the author is not the expected bot, or a commit has a different author;
• mergeable is CONFLICTING;
• a required check failed — see "Which checks matter";
• the diff changes a file that is not a manifest, a lockfile, or a workflow (lockfiles include uv.lock, flake.lock, Cargo.lock, pnpm-lock.yaml), or it changes the bot's own configuration;
• the new version is less than 3 days old, or the release notes and the tag do not exist upstream;
• the package repository, the homepage, or the maintainer set changed;
• a lockfile adds a package with an install script (preinstall, postinstall, prepare).

A version-update:semver-major is not an automatic block. See "Major updates".

For an npm bump, compare the maintainer set of both versions, not only the new one:

for v in OLD NEW; do
  curl -s "https://registry.npmjs.org/PKG/$v" | jq -c '[.maintainers[].name]'
done

A set that shrinks inside the bump window is a block. axios went from 4 maintainers to 1 between 1.13.6 and 1.18.0, which concentrates publish rights on one account.

Which checks matter

Separate required failures from advisory ones. mergeStateStatus is an initial signal, not a complete check result:

Use gh pr checks NUMBER -R REPO --required to identify required checks. If the required set is unclear, confirm with protection and rulesets for the pull request's actual base branch, not necessarily the default branch:

base=$(gh pr view NUMBER -R REPO --json baseRefName --jq '.baseRefName | @uri')
gh api "repos/REPO/branches/$base/protection" --jq '.required_status_checks.contexts'
gh api "repos/REPO/rules/branches/$base" \
  --jq '[.[]|select(.type=="required_status_checks")
        |.parameters.required_status_checks[].context]'

404 Branch not protected and an empty ruleset list mean nothing is required. A 403 means you cannot read the rules. If the required set cannot be established, report it as unknown and block rather than infer passing CI.

Check isArchived first. You cannot merge into an archived repository, and GitHub reports it as BLOCKED with no protection and no rules, which looks like a required check:

gh repo view REPO --json isArchived,archivedAt

Report an archived repository as skipped, not as a CI failure.

Major updates

A major bump is a question, not a verdict: does the breaking change reach this project? Ask the deep-check subagent to state the documented breaking change in one sentence, then test it against the repository.

The evidence is the pull request's own CI. A green build on the pull request proves the new version works there, because the workflow ran with the bump applied. actions/checkout v7 only blocks fork checkout under pull_request_target and workflow_run, so this settles it:

for f in $(gh api repos/REPO/contents/.github/workflows --jq '.[].name'); do
  gh api "repos/REPO/contents/.github/workflows/$f" --jq .content | base64 -d \
    | grep -qE '^\s*(pull_request_target|workflow_run)\s*:' && echo "$f"
done

Merge when the breaking change cannot reach the project and CI is green. Block when it can, and name the mechanism.

A red check is not proof that the bump broke it

Compare against the base branch before you blame the bump:

gh run list -R REPO --limit 6 \
  --json conclusion,workflowName,headBranch,createdAt

Then read the log and name the error:

gh api --allow-escape-sequences repos/REPO/actions/jobs/JOB_ID/logs \
  | perl -pe 's/^.*?\dZ //' | perl -pe 's/(\e|\^\[)\[[0-9;]*m//g' \
  | grep -iE 'error|failed' | head -20

Two examples from one run. A snapshot job failed with an OpenCV aruco C++ compile error that also failed on master — unrelated, so the bump merged. A test job failed with npm ERESOLVE, because @typescript-eslint/eslint-plugin@8.65.0 needs typescript <7 through ts-api-utils — caused by the bump, so it stayed blocked.

HTTP 410 means the log expired. That is unknown, so it is blocked.

Query the advisory database for both versions, not only the new one:

gh api '/advisories?ecosystem=ECOSYSTEM&affects=NAME@VERSION&per_page=5' \
  --jq '.[] | {ghsa_id, severity, summary}'

An open advisory that affects the new version blocks the merge. An advisory that the bump repairs is a reason to merge — name the GHSA in the report, because it tells the maintainer which merges are urgent.

An upgrade is not automatically a fix. Check that the new version is outside the vulnerable range, not merely newer. golang.org/x/image 0.20.0 to 0.38.0 looked like a big catch-up, but GHSA-q675-qj96-32m9 is patched only in 0.41.0, so the bump landed still vulnerable. Block, and say which version would actually close it.

A check that fails everywhere is one broken tool

Before blaming any bump, ask whether the same check fails in unrelated repositories. If it does, it is a broken tool, and it is one problem rather than many. A ruleguard / scan job failed on seven pull requests across four repositories with internal error: package "context" without types, because the workflow installs it with go install ...@latest against a newer Go. It even failed on a pull request that only edited YAML, which the linter never reads — proof on its own that no bump caused it.

Two signals that a red check is not the bump's fault:

• the same failure appears on the base branch;
• the failing job cannot read any file the diff touched.

Ask the user whether a recurring failure is known-broken, and once they say it is, stop re-deriving it in later runs.