Dependabot-core: .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[bot]]

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? :thinking:

[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?

[cdrini]

Would love it if this was bumped in priority :) We got/merged a PR from dependabot https://github.com/internetarchive/openlibrary/pull/3831 4 days ago, and now presumably all up-to-date forks are getting update notifications :/ Mine certainly is!

[raisedadead]

We just enabled dependabot on our repository with ~25000 forks and we have ~900 dependencies. We did not know about this known issue.

A heads up if this would mean any spikes on dependabot's backend and resulting support issues (which I imagine to increase over time as forks get updated).

I for one love what dependabot does and a config to ignore forks would be helpful to us maintainers and save wasted resources on dependabot's end aswell?

If there anything we can do to help with this, please let us know.