Job dependency-update-pull-requests-merged-automatically-when-your-own-checks-pass · revised 12 October 2026
Let dependency update PRs merge themselves when your own checks and rules pass
Update pull requests from your dependency bot merge on their own only when your checks are green and your written rules hold. Every merge is logged with a revert link, and you hold the kill switch.
You might be seeing
- Dozens of bot pull requests wait for a person's click
- Security updates are delayed behind routine ones
No passwords, keys, card details or admin invites needed to start.
What usually happened
Merging other people's code by machine can let in a bad release, and a compromised package has leaked secrets from builds before. The safe design is rules in code, your protected-branch rules left alone, a cooling-off age for new releases and a way to undo each merge. A model must never be the thing that decides to merge.
Who it’s for: Lead of a small team with a pile of dependency update pull requests that nobody has time to merge, and good tests.
Usually starts when: Dependency bot pull requests sit open for weeks, security fixes wait behind them, and your tests already catch most breakage.
The result: A job in your own GitHub account turns on the platform's own auto-merge for a bot pull request only when it meets every rule you wrote: bot author on your list, patch or minor bump, small diff, no new packages, no workflow files, release old enough, all required checks green. Every merge is logged with a revert link, a daily cap applies and a kill switch stops it. A model can only add a hold, never a merge.
Check whether this job fits
Answer these without sending files, tickets, code or logins. Nothing is submitted unless you choose to contact us.
What you get
- The rules file in plain steps
- The job and its settings for your account
- The decision log format and a sample log
- The revert runbook
- The limit-check and replay results
- The kill-switch and token-revocation note
Included
- One repository and one target branch you name, with a bot author list (for example your dependency bot's login)
- Rules in code: patch or minor bumps only, at most 200 changed lines, version bumps of existing direct dependencies only, no new packages, no workflow or build-script files, no protected paths, release at least 7 days old
- The platform's own auto-merge, so your required checks and any required reviews still gate every merge; we never change your branch protection
- A daily cap on merges and a log row for every decision: pull request, rules met or failed, time
- A revert runbook: each merged pull request keeps a revert link, and the runbook shows the 10-minute steps
- 14 days of "would merge" comments only, then your named person switches it on; a kill switch you hold
Not included
- Merging anything not from the bot author list, including your developers' and AI agents' pull requests
- Major version bumps, new packages, workflow files, build scripts or lockfile-only changes without a manifest change
- Changing branch protection, required checks or review rules
- Approving pull requests in place of a person where your rules require a review
- Deploying, releasing or reverting for you: your pipeline and your person do that
- Judging whether a package is safe: only your rules and your checks decide
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
On a test repository, none of 300 rule-breaking pull requests merges and each is logged with its broken rule. All 30 eligible pull requests merge once every required check and review passes; you keep 15 eligible and 150 rule-breaking cases from us until the run. One rule-breaking merge, missing log, bypassed required check or review, or eligible request not merged fails this code smoke test.
Evidence: The test log and the rules file.
On the 10 closed bot pull requests you keep from us until the test run, at least 9 decisions match your pre-agreed merge-or-hold labels (observed 90%; exact one-sided 95% lower bound, rounded down: 60%). We also report results for the other 20 without a rate claim; all known-bad requests, at least 3, must be held, and one known-bad request marked merge fails the whole test.
Evidence: The replay table and your labels.
20 hostile pull requests with instructions in title, body and changelog cause no added merge or forbidden action. A model may add a hold but never remove one; a forbidden action or merge fails this smoke test, which makes no attack-resistance rate claim.
Evidence: The hostile-pull-request log.
On the test repository your person reverts a merged pull request from the log using the runbook, and the branch matches its state before the merge, in under 10 minutes.
Evidence: The timed rehearsal log and the branch diff, which must be empty.
With the kill switch set, 10 eligible requests stay unmerged, including requests with auto-merge already enabled while their last required check is pending. The log shows paused; one merge fails the test, and the job merges nothing during the 14-day comment-only window.
Evidence: The test log and your repository's merge history.
Sign-off. You re-run the acceptance checks with the steps we hand over, read the results and sign off in writing. Payment follows sign-off.
If it fails. If an agreed check fails, you do not pay for this scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- Tests and checks that you trust enough to gate a merge, set as required on the target branch
- A dependency bot already opening pull requests
- A GitHub token limited to this repository that you create and can revoke
- A named person who watches the 14 days of comments, switches the job on and holds the kill switch
- You accept in writing that a merge to the target branch may trigger your pipeline
We stop and tell you if
- The target branch has no required checks, or the tests would not catch breakage
- You want major bumps, new packages or your developers' pull requests merged by the job
- You want protection rules relaxed so that the job can merge
- A merge to the target branch deploys to production and you will not put a gate in front of it
What could go wrong
Each merged pull request keeps a revert link in the log. The runbook shows how your person reverts one merge, or all of a day's merges, in 10 minutes. Revoking the token or setting the kill switch stops the job at once.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A bad release is merged. | Your required checks still gate every merge, new releases wait 7 days, new packages are never merged, and a daily cap limits the day's exposure. A merge cannot be called safe. |
| A compromised release passes your checks. | Checks cannot prove a package is safe. The 7-day age rule, the no-new-packages rule and the revert runbook reduce the exposure; they do not remove it. |
| Text in a pull request or changelog steers the job. | Decisions are code on metadata. A model reads the public changelog only to add a hold, and 20 hostile pull requests are tested. |
| The token is misused. | It covers one repository, you create it and you can revoke it. Branch protection is never changed by the job. |
A separate automated reviewer checks the work and the test results before hand-over. Your named person watches the 14 days of comments, switches the job on, holds the kill switch and decides every revert. No human supervisor from us is included unless your agreement names one, and at launch the work is largely automated.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the rules, bot list, target branch, daily cap and who holds the switch
- Replay your last 30 bot pull requests through the rules; you keep 10 back
- Build the job so every rule runs as code; a model can only hold
- Test 300 generated pull requests that break one rule each, and 20 hostile ones
- Run 14 days of comments only; your person reads each decision
- Review separately, rehearse revert and kill switch, and hand over
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, price, start window and delivery date in writing before you accept, and work starts only after the agreed inputs are in place. An enquiry creates no charge or booking.
Need to keep it working?
Discuss the monthly log check once the job has run live for a month.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Use your platform's own auto-merge and your bot's grouping settings, with your own rules.
- Buy the verdict job, where each bot pull request gets a written review and you click merge.
Questions
Does an AI decide what gets merged?
No. Your rules decide, as code. A model can only add a hold, such as when a changelog mentions a breaking change, and can never add a merge.
Does it change my branch protection?
No. It uses the platform's own auto-merge, so your required checks and reviews still gate every merge.
Can it merge a major version or a new package?
No. Those always wait for a person.
Is a merged bump safe?
We cannot say that. Your checks decide whether it passes. The rules only limit what may be merged without a person.
Does a pass mean it will be right next month?
No. A pass describes items like the test sample on the day of the test. It is not a promise about future items, and it does not replace your own checking.
Send an enquiry
Send us
- Which repository and branch, and which bot opens the pull requests
- How many bot pull requests wait now
- Whether required checks and reviews are set on the branch
- No logins, keys, customer data or payment details in the first enquiry
Later, once you agree
- The last 30 closed bot pull requests as a read-only export, with your label for each (merge, hold)
- A test repository that mirrors your settings, which you create
- Your confirmation that you created a repository-limited token when you switch on; never send the token to us
- The name of the person who holds the kill switch
You keep your repository, your branch rules and every login. We build and test on a test repository you create, and hand over the job. You install it with a token limited to this repository that you create and can revoke, and we never hold it.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “dependency-update-pull-requests-merged-automatically-when-your-own-checks-pass” as the subject.