Dependabot and forks

Development
1

So there’s thing dependabot which opens PRs with updated dependencies. I find that midly annoying and we almost never merge them but they have some value as a notification that something newer exists. It used to be a specific integration for syncthing/syncthing that we enabled there.

Now, though, when it’s taken over by GitHub and apparently triggered by the presence of a .github/dependabot.yml this has the effect of also enabling dependabot on forks, as soon as they have a main that contains the config file in question. This is supposedly going to be fixed but has been open since 2019.

I find the original PRs annoying and mostly just close them to begin with, but then getting the same PRs again on my personal fork(s) is even more annoying. Should I (and everyone else) just live with it, or do we disable dependabot for the time being? I vote for the latter.

(There might be a workaround in blocking dependabot from my repo, just thought of that now, can try it… Doesn’t seem like that’s possible with this bot.)

A workaround is apparently to create an empty branch (without the config file in question) and set that as the default branch of the fork… I’m OK with this, as it solves my problem. Remaining question is if it’s unsociable to foist dependabot on any poor sucker who happens to fork our repo…

2

Let whoever forked deal with this.

I guess I find it strange that we outright close the PRs that thing raised.

I think we should move deps forward as presumably we’re picking up fixes/improvements (and breakages) along the way.

3

I don’t care much either way. I looked around for something similar, e.g. just a service that lists possible updates, but couldn’t find something.

I am not really impressed by dependabot. Too many in-your-face weirdnesses that go unaddressed (e.g. grouping dependencies is open for ages too, a delay on rebasing would be useful, …).

In general I’d be in favor of staying on whatever version worked unless something relevant to us improved. Less chance of breaking something that already worked and less build requirements. However with the go modules way of doing this, we might as well bump versions as we might get a higher version anyway through dependencies requiring a higher version (e.g. it was quite confusing when quic broke, because we didn’t upgrade - a dependency did).

4

Not sure if I am on the same “if it works don’t update it” wavelength. For the same reasons we bitch to our users to update.

5

Well, you try merging them in a reasonable fashion… It opens ten PRs. Merging one causes the other nine to rebase, which in turn is about 9*15 build jobs on our server, taking ages. Merge one, the other eight rebase, etc.

There is a value in terms of letting us know there is an update, but actually doing the update is a thousand times easier to handle manually.

6

Sure, this pain I understand. I guess we could disable builds for depenadabot PR’s, yolo merge them, and mop up manually later.

Perhaps there is a way to get it not to rebase?

7

I think the rebase is required because go.sum is prone to conflicts, but I’m not sure. Perhaps once things are rolling there are fewer PRs at a time. I’m not excited about yolo merges since a fair amount of the time updates will break something (quic of course in every update, gopsutil breaking and unbreaking the various bsd builds on every other update, etc). So on that front I like that there is a PR per dependency, but it sure would be neat to select multiple and say “merge these”…

8

Anyway. I’ve told dependabot to stay out of my fork so I’m good. I guess we let it stick around and hope that it becomes house trained in the end.

2 Likes