GitHub Dependabot PRs

Every now and then I get PRs from GitHub’s Dependabot. I used to routinely accept them, then once it caused grief and only after-the-fact one of the python-dev Git experts said not to accept it.

Should I accept these two?

  • Bump sphinx from 5.2.3 to 5.3.0
  • Bump sphinx-lint from 0.6.6 to 0.6.7

Is it generally good to accept these (was that one problematic thing a rare occurrence) or should I routinely reject them?

You should not accept them, as they would make unwanted changes in your repo that later end up in unrelated PRs you make for the upstream repo.

This is a long-standing issue with dependabot: Allow disabling dependabot on forks · Issue #5914 · dependabot/dependabot-core · GitHub

I got so annoyed by it that I deleted the config file in my repo’s main branch, so now I have to take care to create branches for PRs from the upstream/main branch rather than origin/main (origin being my fork).

1 Like

On which repos are you getting them?

If forks, just close them. If you close with @dependabot ignore this dependency you’ll get a little less spam in the future. Better yet delete the config like @merwork suggested.

The good news is GitHub recently said they’re finally working on a fix for the fork spam.

@hugovk I recently tried adding a protected branch rule making all branches matching dependabot/**/* read only… and I think it might be working…

On my fork of python/cpython. I will close them with your magic comment.

Perhaps we can add info on the devguide about ignoring dependabot on forks.

1 Like

@hauntsaninja I just tried it on my fork of with “Branch name pattern” = dependabot/**/* and “Lock branch” enabled:

Then updated with upstream and Dependabot still opened 10 14 PRs:

The branch protection rule says it currently applies to those 10 14 PR branches, but it didn’t prevent it opening the PRs:

Do you have different settings?

Looks like this is moot! Dependabot pull requests off by default for forks | GitHub Changelog


The terse changelog blurb does not state what happens to already existing forks. If dependabot is re-enabled on the main repo, will it automatically disable running dependabot on existing forks, or will all 24.8k of the forks need to manually disable it?

Correct, not fully moot.

The existing 24.8k forks need to disable at


As an alternative, I’ve been happily using Renovate in my projects, which doesn’t create PRs for forks (unless specifically enabled in upstream config).

1 Like