Hacker News Reader

Comment by janejeon | Hacker News Reader

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(!)

View on HN

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.

Reply on news.ycombinator.com