Hacker News Reader

Comment by woodruffw | Hacker News Reader

I don’t disagree about automating intentionally, but it’s worth noting that Dependabot isn’t enabled by default: you have to explicitly configure it.

(The larger problem here isn’t even Dependabot per se, since all Dependabot does is fire PRs off. The problem is that people then try to automate the merging of those PRs, and end up shooting themselves in the foot with GHA’s more general footguns. It also doesn’t help that, until recently, GitHub’s documentation recommended using these kinds of dangerous triggers for automating Dependabot.)

View on HN

> Dependabot isn’t enabled by default: you have to explicitly configure it.

Really? Dependabot runs on a number of my repositories without my having consciously enabled it.

> Really? Dependabot runs on a number of my repositories without my having consciously enabled it.

I've never experienced this. Do you have a `.github/dependabot.yml` file in your repository? That's how it's enabled.

(GitHub has muddied the water here a bit by having two related but distinct things with the same name: there's "Dependabot" the subject of this post, and then there's "Dependabot security updates" which are documented separately and appear to operate on a different cycle[1]. I don't know if this latter one is enabled by default or not, but the "normal" one is definitely disabled until you configure it.)

[1]: https://docs.github.com/en/code-security/dependabot/dependab...

> I've never experienced this. Do you have a `.github/dependabot.yml` file in your repository? That's how it's enabled.

Nope. Example: https://github.com/m50d/tierney/pull/55

I'm at a loss to explain that! My only other guess is that you might have enabled Dependabot at some point further back in history, when it was a third-party integration and directly owned by or integrated into GitHub.

Do you have a Dependbot entry in your account/org-level applications?

> Do you have a Dependbot entry in your account/org-level applications?

I don't think so. I have no memory of such a thing, and there is no org.

Okay, I have no idea then. I guess perhaps at one point Dependabot was enabled by default for some people, although that strikes me as a bad idea and I can only assume they've disabled it since then, since I haven't seen this on any new repository I've made.

My understanding, and it may be wrong, is you may be grandfathered in to an ancient Personal, Public Repo opt-out from a brief window of time just after GitHub was excited to announce the first/earliest version of Dependabot and was hoping it would clean up some Open Source supply chain attacks and just before GitHub realized Dependabot was a useful thing to charge people an upcharge on (now under the umbrella known as GitHub Advanced Security). I believe that GitHub auto-opted in a lot of personal accounts with "significant" Public repos (anything with a bunch of forks/stars, or a package identifier visible in the dependency graphs of the Ruby or npm ecosystems, or any of the things that awarded "badges" like Mars Rover badge or the Artic Vault badge). There's a page buried in your Personal Account Settings to turn off that ancient Dependabot option. (I'm on a work machine without access to my personal account at the moment or I'd directly tell you where to find it.)

Are these repos forks of projects that already set up dependabot? Or maybe created from templates that included dependabot configuration?

Nope. My own original projects.

Could it have been a Dependabot security update? These are different from normal Dependabot updates and do not require `.github/dependabot.yml`.

Reply on news.ycombinator.com