Adopt Renovatebot to help keep dependencies up-to-date

[pnacht]

Hey, it's Pedro (see #3722) and I'm back with another security suggestion.

Use case

kotlinx.coroutines has many dependencies declared in a few different places. Looking at the commit history, I see there is significant effort to keep these dependencies up to date.

Renovatebot is a GitHub App that can help automate some of this work by sending routine PRs that update these dependencies for you. It can be configured to send PRs as soon as a dependency's new version is released, or to group the dependencies together.

I unfortunately can't really help the project install Renovatebot, since it requires maintainers to install the App (see the docs). However, I'll send a PR with a suggested config file to help you as much as I can.

Note that the standard Renovate App requires write-access to the repository. If this isn't something you're comfortable with, there's also the Forking Renovate App, which only needs read-access. However, Forking Renovate can only send PRs to the repo's default branch (master), not to the recommended develop branch.

An alternative is usually GitHub's Dependabot, but it unfortunately doesn't work with projects that set versions in a gradle.properties file.

Prior Art

These are the PRs Renovate created on my fork, which I've configured to group dependencies together: pnacht#12 (minor version bumps), pnacht#13 (major version bumps). Or check out out the single-dependency PRs it would otherwise send.

[dkhalanskyjb]

Hi!

Looking at the commit history, I see there is significant effort to keep these dependencies up to date.

I think this perception is inaccurate.

The dependencies we use and update the most are Kotlin, atomicfu, and Dokka, which are all first-party. We carefully choose the moments when we upgrade them; a bot pestering us would add nothing of value.

We also depend on the libraries for which we provide integrations. The scheme is like this:

library --------------------> user project
  \                            /\
    \--- our integration -----/

The user will typically have their direct dependency edge on the library with a higher version than our dependency edge on that same library. That's a good thing: we don't want to force the user to upgrade to a higher version just because they use our integrations; this has to be an explicit choice on their end. Dependencies like Android, Reactor, RxJava2, RxJava3, JavaFX, BlockHound, and probably others are like that. In essence, we knowingly postpone upgrading them for as long as possible, and the bot, again, would only be an irritation.

Lastly, we depend on some utility things, like JUnit for testing, Kover for code coverage analysis, etc. We upgrade them when we feel the need to, but they are insignificant in terms of what reaches the end user of our library.

Of the things we actually depend on and ship that could, in theory, affect the users, I think there's only JNA and Byte Buddy, for the kotlinx-coroutines-debug module. Looking at https://github.com/pnacht/kotlinx.coroutines/pulls?q=is%3Apr+is%3Aclosed, however, I don't see the suggestions for upgrading those, even though both had new releases.

So, I don't see what value the bot could bring to our project specifically. Certainly not enough to provide it with write access.