How to disable for a fork?

[hugovk]

I enabled Dependabot for a fork (https://github.com/hugovk/pytest), to make sure it was working smoothly before creating a PR to add it upstream (https://github.com/pytest-dev/pytest). Upstream is now using it, it's working well, thanks!

However, I now want to disable Dependabot for my fork but cannot find a way.

https://app.dependabot.com/accounts/hugovk says:

You've successfully migrated pytest to GitHub 🎉

At https://github.com/settings/installations/8631454, Dependabot Preview only has access to other repos:

At https://github.com/hugovk/pytest/settings/security_analysis I have everything disabled:

Deleting https://github.com/hugovk/pytest/blob/master/.github/dependabot.yml is not an option, because this is a fork, and it needs to be kept in sync with upstream.

How can I disable Dependabot for my fork?

Package manager/ecosystem

Python

Manifest contents prior to update

version: 2
updates:
- package-ecosystem: pip
  directory: "/testing/plugins_integration"
  schedule:
    interval: weekly
    time: "03:00"
  open-pull-requests-limit: 10
  allow:
  - dependency-type: direct
  - dependency-type: indirect

https://github.com/hugovk/pytest/blob/master/.github/dependabot.yml
https://github.com/hugovk/pytest/blob/master/testing/plugins_integration/requirements.txt

---

Edit: as the 2022-11-24 solution is obscured by the thousands of hidden items below, here it is for clarity:

Hmm... from when we shipped this on November 7th going forward, no repos should be default opted-in.

One exception is any repo, fork-or-no-fork will be automatically opted in if you've selected the Automatically enable for new repositories option in your user or org settings. But that's essentially inheriting a manual opt-in.

Forks that were created before November 7th will require manual disabling... we considered disabling them, but couldn't easily distinguish between those who did/didn't manually enable it from the beginning, so it was safer/more predictable for users if we left them untouched.

To disable, as @hugovk mentions above you need to either delete/re-create the fork, or click Disable on the forked repo's /settings/security_analysis page:

For PR's that were already sitting open when you disable Dependabot, I think nothing further happens to them unless you do it. They won't get auto-rebased or auto-closed.

[Mariatta]

This is happening in CPython repo as well which has 17K forks. It would help us greatly if dependabot can be disabled in forks. Thanks.

[feelepxyz]

We're aware of this issue and planning a fix. The workaround for now is to delete the fork and re-create it without enabling Dependabot security updates. Dependabot version updates (setup from config file) isn't enabled by default on new forks but will be if security updates has ever been turned on and since disabled.

[patcon]

Thanks for clearly communicating! Any "ish" timeline on this?

(I have unrelated issues in the forks, so deleting and recreating isn't quite as easy as it could be.)

[feelepxyz]

@patcon we'll get to it in the next couple of months :/ going to bump it up again with the team and see if we can get to it sooner.

[wesinator]

Getting this issue on a fork of https://github.com/EFForg/https-everywhere

Disabling actions did not prevent new PRs being generated

[ldez]

Seems to be a duplicate of #2198

[trivikr]

@feelepxyz bumping it again, as it has been three months since this comment in #2804 (comment)

[featheredtoast]

The workaround also doesn't work for forks I want private because I cannot change visibility of a (Github) fork, so I'm mirroring instead. Would the solution here also allow us to disable dependabot in mirrored repositories?

[return42]

I think there is a need to act here because each fork has a master branch that cannot be changed from upstream after the fork is created. Those dependabots from forks will run infinite! At least as long as the owner of the fork does not fix his master branch what is expectable for 99% of the forks. Thinking global, this is a totally unneeded wast of resources and energy ...