.dependabot/config.yml and forks

[LeoColomb]

.dependabot/config.yml is a great feature, thanks!

That said, I faced an unwanted behavior.
Considering two accounts with Dependabot enabled, if an account forks a repo of the other one containing a .dependabot/config.yml file and with outdated dependencies, Dependabot will be auto-activated and will open pull requests on the forked repo.

As a real example, I forked dependabot-core and got four PR in the minute.

[feelepxyz]

@LeoColomb agreed on not auto-adding forks!

We also want to allow running on forks so won't be a super quick fix on our side. The current plan is to not auto-add forks with config files but show these in the Dependabot dashboard where you can click to enable the fork.

I'm currently working on a repo details page in the dashboard where we can do this so going to get back to this after getting that out.

Thanks for getting in touch!

[connorshea]

Maybe have dependabot open an issue that lets the user opt in to running on the fork?

[greysteil]

Yeah, I think surfacing in the dashboard first is the way to go - don't want to create issues unless we have to. What was your experience at GitLab of folks forking repos with a config file?

[connorshea]

Generally it didn’t matter much since the only config file that really mattered for GitLab was the CI YAML, and CI didn’t typically open merge requests on the project or modify the project state at all (or if it did, it’d need a private token anyway, so it would just fail unless someone went through the trouble of setting it up).

CI would run for the latest commit on master and any newly-pushed commits, but it wasn’t a problem.

Dependabot is pretty different in that regard, so my knowledge probably isn’t super useful here unfortunately.

[LeoColomb]

Forked repositories have issues disabled by default on GitHub. So opening an initial issue is not possible. 🤔 😉

GitLab of folks forking repos with a config file

You mean with .gitlab-ci.yml? Well it auto enable GitLab-CI, but:

• GitLab CI do not run anything before the first push
• There is a option to disable it at any time

---

Edit: Connor beat me to responding, but yes.

[connorshea]

The only other thing I can think of that’d be relevant would be things like CI Variables and other project settings. I’m fairly certain none of the project settings are carried over on a fork, and CI Variables are supposed to be used for API Keys, etc, so they definitely weren’t carried over.

[connorshea]

.gitlab-ci.yml files do actually have the ability to run certain jobs only on specified repositories, I forgot about this feature:

job:
  only:
    - branches@gitlab-org/gitlab-ce
  except:
    - master@gitlab-org/gitlab-ce

https://docs.gitlab.com/ce/ci/yaml/#only-and-except-simplified

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within seven days. Thank you for your contributions.

[LeoColomb]

Still an issue, right?

[feelepxyz]

@LeoColomb yup! Still on the radar 👍

[eps1lon]

I'm wondering why there is no option to disable dependabot. I removed access to one of the forks via github UI but it's still listed in the dependabot dashboard. Furthermore the upstream repository is no longer getting updates and in a permanent "checking for updates" state.

[rebelagentm]

@feelepxyz Thoughts on what's going on here regarding @eps1lon's comment?

[feelepxyz]

@eps1lon yes this was possibly due to a Dependabot outage which meant that jobs took ages to process. This should be fixed now and the queue times should be back to normal. Has the repo you removed been deleted from the UI?

[eps1lon]

@feelepxyz Forgot about this. I tried again today and it is now removed from the dependabot UI. This should prevent dependabot from opening PRs on my fork. If this works then revoking access resolves this issue for me.

[SudharakaP]

Is there any why that you know to stop dependabot PRs on forks if we migrate to the v2 (with dependabot.yml file based configuration; https://help.github.com/en/github/administering-a-repository/configuration-options-for-dependency-updates).

[feelepxyz]

Is there any why that you know to stop dependabot PRs on forks if we migrate to the v2 (with dependabot.yml file based configuration; https://help.github.com/en/github/administering-a-repository/configuration-options-for-dependency-updates).

Yes, Dependabot v2 won't be automatically enabled on forks and you have to enable it from the Dependabot UI under Insights > Dependency Graph > Dependabot.

There's currently a bug where it will start sending you PRs if you've somehow installed the Dependabot v2 app on an old fork and then rebase the source which has since added the config file (the app installation is transparent but happens when you enable Dependabot security updates for example).

[SudharakaP]

Is there any why that you know to stop dependabot PRs on forks if we migrate to the v2 (with dependabot.yml file based configuration; https://help.github.com/en/github/administering-a-repository/configuration-options-for-dependency-updates).

Yes, Dependabot v2 won't be automatically enabled on forks and you have to enable it from the Dependabot UI under Insights > Dependency Graph > Dependabot.

There's currently a bug where it will start sending you PRs if you've somehow installed the Dependabot v2 app on an old fork and then rebase the source which has since added the config file (the app installation is transparent but happens when you enable Dependabot security updates for example).

@feelepxyz : Thanks much for your response. So just to confirm, re-creating the fork should help I guess? 🤔

[feelepxyz]

So just to confirm, re-creating the fork should help I guess? 🤔

Yup!

[hazendaz]

When will the bug be fixed with forks? It seems completely backwards that I have to delete a fork and recreate it. I don't care to do that and this is an incredible mess. I'm getting daily bast of PRs that is incredibly high for repos I work on and its too easy to accidently merge on the fork where I don't want the merge. This has been an outstanding issue before V2 came into the picutre now for going on 2 years. So please make this a priority.

[onedrawingperday]

@gohugoio recently added dependabot to its master repo.
Currently there are some 5.3K forks of the main repo. Lots of these were created before v2 of .dependabot.

You cannot really expect people to update to v2 by deleting their forks and associated pull requests history so that they stop receiving these unwanted Pull Requests.

Please do consider making this issue a priority.

[s-weigand]

IMHO the easyest fix for this issue would be to add a new field to dependabot.yml which might i.e. be called repo, which could lead to 3 different cases.

• no repo field => current behaviour
• repo field value matches repo name => do PR's
• repo field value does NOT match repo name => don't do PR's

That way you could get the following benefits:

• Backward compattiblety
• No unwanted PR's, since repo value and name mismatch, if it is a contrib fork (as I guess most are)
• Option to activate dependabot on forks (i.e. hard forks can just change the repo field value)

IMHO this is a case where users don't want all the automagic assumptions, but have full control.
When my dependabot Tesla is about to crash in a tree, I want the option to deactivate the autopilot. 😉

[helfper]

Can we just get a @dependabot ignore this repo to make Dependabot go away from the repo/fork?

[javierm]

Our workaround so far to avoid spamming our 800+ forks:

• In the master branch, we've got no dependabot config file
• In another branch, we've got a dependabot config file with the target-branch: master option

When we want to run dependabot, we make the latter branch the default one, and then make the master branch the default branch again.

Of course, now it's August and most people potentially interested in forking our project are on holidays, so the risk of someone forking the project while we're changing the default branch is very low 🤔. Might not work for projects people are forking constantly.

[GoliathLabs]

@feelepxyz any updates on this?
I really like dependabot and recommend it to the projects I use in my own infrastructure to make updating dependencies easier. However, most of them turn it off after a while because people with forks complain about dependabot's PR spam.
I think that after 3 years now, this problem should be worked on, as some projects would very well want to use dependabot but don't because of this situation. @nstringham has pointed out a good way to compensate for this.

If this is resolved, dependabot would get many more users and the debates and conflicts regarding the use of dependabot for a project would be much easier to resolve.

[hugovk]

I forgot one project uses dependabot and made the mistake of updating my fork from upstream/main and got 26 spam PRs:

[mikehardy]

https://docs.renovatebot.com/configuration-options/#includeforks

Renovate by default skips all forks - looks like a good alternative if change in the repo you manage is possible. I've seen renovate used to good effect in the ACRA repo and will consider it for my repos since the fork PR thing is kind of a showstopper as it induces a lot of contributor friction in fork-based repos.

[patcon]

Renovate is also fully open source

[jeffwidman]

👋 Hey there! This is super annoying, and very much on our radar. Unfortunately, I can't give any promises on timeline etc, but it is something we plan to fix.

However, it's also tracked over in #2804, so I'm going to close this as a duplicate. I realize this one is earlier, but the other one is the one we're tracking internally on some project boards, so just easier to keep that one as the canonical reference ticket.

[koppor]

👋 Hey there! This is super annoying, and very much on our radar. Unfortunately, I can't give any promises on timeline etc, but it is something we plan to fix. However, it's also tracked over in #2804, so I'm going to close this as a duplicate. I realize this one is earlier, but the other one is the one we're tracking internally on some project boards, so just easier to keep that one as the canonical reference ticket.

@jeffwidman The mentioned issue is closed with > 1.700 comments. Could you summarize the result for us?

[hugovk]

Summary:

• For new forks (after 7th November 2022), it is already disabled.

• For old forks, you can delete and re-fork, or disable it via the settings at /settings/security_analysis: