Add dependabot where it's convenient?

[Michael1993]

Basically the title. @aepfli mentioned this in Discord and I think it warrants a proper discussion.

[aepfli]

maybe also for gradle build dependencies and for github action updates?

[Bukama]

I'm strongly voting against Dependabot. We decided to choose our dependencies manually and by purpose we don't use the least versions.

So a spamming tools who creates countless of spamming issues or pull requests, which we all auto-close because we don't want to upgrade is non-sense and only bloats tons of shit.

[beatngu13]

@Bukama I think one has to differentiate between critical / production code dependencies such as JUnit—where we indeed want hand-crafted updates—and non-critical / test code dependencies like AssertJ. For the latter, I find tools like dependabot very useful for two main reasons:

• One doesn't have to manually trigger tooling such as the Gradle Versions Plugin (or is there a sensible workflow to automate this?)

• One also gets infrastructure updates for e.g. GitHub Actions

Plus: it is super easy to have a whitelist or a blacklist. Therefore, there is no spamming unless you fuck up the configuration. 😉

So when it comes to updating non-critical dependencies, what is more comfortable than getting notified via a PR that is (most of the time) ready to be merged?

[Bukama]

Assigned to @nicolaiparlog to judge as founder as two maintainers (@aepfli and me) have no common point of view.

[signed]

There already is a PR to add dependabot to convert-junit4-to-junit5.

[beatngu13]

@signed thx for the link, I wasn't aware of that one.

As pointed out by @Bukama, there is no common POV so far. So I guess we shouldn't merge anything Dependabot-related in any Pioneer repo until we / @nicolaiparlog decided how to proceed.

[nipafx]

As I see it, dependabot comes with a cost and a benefit:

• cost: adds issues/PRs that must be dealt with (who said "annoying"?!)
• benefit: prevents outdated dependencies

For a project that is as loosely maintained as ours, I consider the cost to be non-negligible. The benefits, otoh, seem somewhat negligible:

• only one run-time dependency that we keep purposely "outdated" (the smallest minor version that supports our feature set)
• build-time dependencies are mostly test-related
• JUnit Pioneer is used during testing, so I assume it is removed from the app's attack surface

[nipafx]

I was told, that dependabot also updates Gradle and GitHub Actions. They have access to our secrets here on GitHub, so keeping them up-to-date is relevant for us.

A teensy bit of research unearthed two nice features:

• accept/block lists, so we could exclude JUnit 5 dependencies
• non-live updates (e.g. weekly/monthly) to reduce number of PRs

This convinced me that we can give dependabot a try if we configure it as described above. I vote for monthly PRs, so we can work through all of them at once.

[nipafx]

Since I need to act as a tiebreaker, I'm voting for a dependabot trial. :)

[aepfli]

i am not sure, that this is closed based on dependabot/dependabot-core#2280 :D not gradle kotlin dsl support

[beatngu13]

Yeah, currently GHA updates only. 🤷‍♂️