I just wish it natively supported a way to "auto-merge" based on semver ranges (e.g. auto-merge all minor updates for dev dependencies, patch for prod dependencies). Unfortunately, neither the option of "just use this GitHub Action!" (incredibly difficult to setup when you're using a non-GHA CI) nor "just turn on auto-merge" (which blows past the semver range requirements) is suitable, so I'm forced to stick with renovate, which has the additional pros of being able to have a centralized config you can share elsewhere, and the ability to update docker compose files(!)

This plus the fact that Dependabot is not able to update Docker Compose files at this time.

The other problem that I have is there is no easy way (probably for good reason due to potential abuse) to manually trigger Dependabot. So Dependabot might run once a day or not do so for quite a while.

I have found a workaround for this since it appears that Dependabot does reliably trigger when .github/dependabot.yml is updated. One quick hack to insert a commented timestamp later... I now have a way to make sure Dependabot runs when I do want it to.

> This plus the fact that Dependabot is not able to update Docker Compose files at this time.

https://github.com/dependabot/dependabot-core/issues/390 upvote and/or implement it as a fork and run it in an Action.

> The other problem that I have is there is no easy way (probably for good reason due to potential abuse) to manually trigger Dependabot. So Dependabot might run once a day or not do so for quite a while.

There is, it's just hidden in https://github.com/:org/:repo/network/updates > click "last updated ..." and then click "Check for Updates" and it'll start a manual run.

Both are just such a horrible DX/hacky solutions that you have to go out of your way to implement/do... dependabot is filled with stuff like this, of stuff that should be simple but simply isn't (or isn't implemented at all, so you need to hack it to do so). Both are simply non-solutions when you can simply just drop in a renovatebot, have a config telling it exactly what to do, and it "just works".

Totally agree on all points, I'm just letting folks know the recommended solution if they choose to use Dependabot.

As a side note, automerge is... complicated. I've always felt that having it means that people will be mad when it does something bad (e.g. automerges the inevetible npm credential theft update), and they'll be mad if it doesn't exist because they're so sick of the unending stream of PRs, so you're kind of damned either way. At this point, I fall on the side of "let people do the unsafe thing so they shut up about not being able to do so" but that's not the side the security team generally falls on.

Disclosure: one time PM on Dependabot

My big issue is that I wish Dependabot sometimes worked at a higher level. It makes all these pull requests at the CVE specific dependency level and that's rarely the level I care about. So many of those are dependencies of dependencies and just "lock-level" PRs. I understand that sometimes that's the approach least likely to break things, but it's also the approach that most doesn't reflect how I work: I don't know what that dependency of a dependency is, please send PRs that update higher level dependencies I care about.

> The other problem that I have is there is no easy way (probably for good reason due to potential abuse) to manually trigger Dependabot.

One of the announcements at BUILD this week was that Dependabot was getting added to a list of "Push protection" tools in GitHub Advanced Security so that it would run at least every push (and also optionally block pushes that don't address Dependabot concerns). Though it will be paywalled behind GitHub Advanced Security.

Auto merge seems like a disaster tbh. I can’t count the number of times semver has been wrong and a patch was breaking.

It’s so easy to end up depending on a behaviour which is a bug.

Waiting for Yarn v2/v3 support in Dependabot has been a saga.

https://github.com/dependabot/dependabot-core/issues/1297

Lol truly.

The short answer is that the Dependabot team can't support all the ecosystems people want without hiring a dozen engineers who have expertise in those ecosystems. The best choice IMO is to move to a model where the community (and ideally the package manager maintainers) can implement their own updaters (ideally using the package manager directly, so support for yarn whatever can just be "update the yarn Dependabot updater to use the newest version of the yarn updater" without the Dependabot team having to care). GitHub even has a platform for running untrusted code, so...

Disclosure: was once my problem, no longer :)

That would be nice. It could even run on top of the GH Actions infrastructure now.

Reading between the lines from comments in that thread, it seems like part of the overhead in maintaining dependabot is that there is ruby code reimplementing yarn logic to do in-place lockfile updates behind the scenes. I'm sure it is nice to avoid checking out the whole repo, but it would also multiply the maintenance workload exponentially.

> That would be nice. It could even run on top of the GH Actions infrastructure now.

https://github.com/thepwagner/action-update being an example of this (and showing go, docker)

> it seems like part of the overhead in maintaining dependabot is that there is ruby code reimplementing yarn logic

The entire maintenance burden of dependabot is "reimplement logic that package managers already do to determine the update strategy." Using package managers functionality for this would indeed make this a lot easier, though even then package manager support for specific things might not be universal.

That said, it's possibly easier to go to the package manager and say "we'd like to implement/for you to implement feature X that will enable Dependabot as well as the underlying functionality Dependabot was missing, that your users probably already want" than the opposite problem of people asking Dependabot to write a bunch of ruby to re-implement something that already exists.

If you want an alternative to Dependabot, try Renovate [0].

[0]: https://github.com/renovatebot/renovate

Or use both.

Dependabot is annoying if you use Nix since all of it's PRs are wrong.

To be fair to Dependabot, Nix isn't supported, so I'm not sure how the PRs could be right?

That's not my problem. Spamming my project with broken PRs is annoying. Not supporting Nix is not a good enough excuse to spam me.

It shouldn't be automatically sending PRs for nix in the first place, right? Did you enable version updates? You can turn security updates off via https://docs.github.com/en/code-security/dependabot/dependab...

FWIW, I don't think security updates are turned on by default anymore, so new repos won't have this problem.

>It shouldn't be automatically sending PRs for nix in the first place, right?

That's the problem it tried to update dependencies without touching nix which would messed up the build. It assumed it knew how to update it, but did it wrong.

It was initially an one-man side project, inspiring how it grew!

It was initially an internal tool at GoCardless (YC S11). Good team. Would gladly work with any of them again.

I very much appreciate Dependabot! I like how it can pick up dependencies in interesting places.

For example, the Globus @ Stanford web site (https://globus.stanford.edu) uses GitHub Pages (repo at https://github.com/stanford-rc/globus.stanford.edu). I have a Gemfile in the repo: When I want to test changes locally, I use Bundler to install everything I need, and to launch Jekyll. Even though the Gemfile isn't used 'in production', Dependabot still warns me, so that I don't run older, vulnerable software on my laptop.

At the same time, I can't be sure if Dependabot is picking up dependencies for my Python project.

In my latest project (https://github.com/stanford-rc/globus-group-manager), I'm using pyproject.toml to hold all of the Python dependencies for the project, something that Setuptools is now supporting experimentally (woot!). I've configured Dependabot, and it has picked up my repo's `pyproject.toml` file, but I can't tell if it has actually cataloged my Python dependencies.

Looking around the web also does not give me a clear answer. For example, https://github.com/dependabot/feedback/issues/57 is titled "pyproject.toml support", but it refers specifically to Poetry (and indeed, Poetry v1 is listed as supported at https://docs.github.com/en/code-security/dependabot/dependab...). But Setuptools is not.

https://github.community/t//2576 asks about Setuptools support, and has been pretty dormant. I thought setup.cfg was supported after https://github.com/dependabot/dependabot-core/pull/3423, but another project of mine (https://github.com/stanford-rc/mais-apis-python/network/depe...) doesn't show anything for setup.cfg.

To be clear, I am very glad that Dependabot exists! I'm also glad to see it being used heavily inside GitHub. I hope this helps Dependabot expand to include more coverage for new and existing ecosystems.