Let renovate handle dependency updates in jenkinsci/jenkins

[Alexander Brandes]

Hey everyone,

dependabot does a good job at handling single artifacts, but it does a bad to no job handling modules of monorepos, see babel -cli, -core, -env, etc. for example.

This typically leads me to moving several submodule dependency update PRs into a single PR, before reviewing, considering updating one part of a dependency without the other often doesn't work out well.

See #6878 and #6879 landing in #6877 for such a case.

This is just one example, there are more dependencies that fall into this category.

I create a PoC of using renovate over dependabot on core available on https://github.com/NotMyFault/jenkins-renovate-poc

renovate is very well able to create these kinds of "merged" PRs for submodules of a dependency, see #4 for example.

For the reasons outlined above, I'd like to see renovate to handle dependency updates in core in the future.

Kind regards

Alex

[Alexander Brandes]

Small ammandment: The semantic commit messages on the PoC can be turned off, but are picked up, because recent (my) commits use them.

[Gavin Mogan]

I'm a big fan of renovate, so I think its a good idea, but I also
don't touch core, so have no idea what the impact would be.

> --
> You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/456baae8-e49f-4d87-8d3e-0038257ea5d4n%40googlegroups.com.

[Alexander Brandes]

> don't touch core, so have no idea what the impact would be.

The PoC contains a renovate file instead of the dependabot file, but the configuration has been carried over.

The transition would be a drop in replacement, if renovate is already installed on the org, otherwise someone with the sufficient permissions has to do that and enable it for core.

> I'm a big fan of renovate, so I think its a good idea

So am I, using it frequently in other projects.

[Tim Jacomb]

+1 for renovate for at least JS deps, dependabot doesn’t support yarn v3 either so we would need to move at that point anyway 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DuusFce4CdvXeoxb6Hck_t2kiOs77%3DoE5Hz8J6H%2BM0ZxsA%40mail.gmail.com.

[Basil Crow]

+1 for Renovate for JavaScript dependencies, for the reasons you have
pointed out: it does a better job of combining multiple updates
together, increasing the success rate of the resulting proposed
change.

Is there a compelling reason to prefer Renovate for Jenkins core Java
dependencies? I can think of one reason to prefer Dependabot in this
scenario: it is consistent with our technology choice for managing
Jenkins plugin Java dependencies. Using the same technology to manage
Jenkins core Java dependencies and Jenkins plugin Java dependencies
buys us the advantage of consistency and familiarity. For example,
over the years I have become familiar with Dependabot's
implementation, includings both its strengths and weaknesses, and I
have stepped through its Ruby code in a debugger on more than one
occasion to solve some mysteries (despite the fact that I am not much
of a Ruby programmer). Switching to a new technology stack for
managing Jenkins core Java dependencies while retaining the existing
technology stack for managing Jenkins plugin Java dependencies would
increase cognitive load by forcing developers to learn a new
technology stack (Renovate) while not allowing them to forget the
technology stack they already know (Dependabot). This wouldn't be out
of the question if the advantages were compelling enough, but you did
not present an argument that they were.

[Alexander Brandes]

> Is there a compelling reason to prefer Renovate for Jenkins core Java dependencies? 

dependabot and renovate can manage Java dependencies equally fine, the drawback for frontend deps apply here too, you get one PR each, if that is a reasonable and frequent concern (it is not from what I've seen).

Although, I don't think we need two bots alongside for different package ecosystems, when one bot can do both.

If renovate doesn't turn out well for Java dependency updates or exposes unforeseen issues that can't be fixed, we can still switch back to dependabot for java dependency updates.

[Basil Crow]

On Mon, Jul 18, 2022 at 2:48 PM Alexander Brandes <mc.ca...@gmail.com> wrote:
> Although, I don't think we need two bots alongside for different package ecosystems, when one bot can do both.

We do if we want to optimize globally (organization-wide) rather than
locally (repository-wide) for decreased cognitive load, as I already
explained in my last post. And successful long-term maintenance
involves carefully managing cognitive load, so I think we do want to
optimize globally. Combining multiple Java dependency updates together
is indeed an advantage, but I do not think it is a compelling enough
advantage to deviate from the technology stack we already use to
manage Jenkins plugin Java dependencies given the concomitant
permanent increase in cognitive load associated with using two
different technology stacks concurrently for the same purpose
(managing Java dependencies). If combining multiple Java dependency
updates together is the only advantage, then I would be in favor of
changing the technology stack used for managing Jenkins core Java
dependencies if and only if the technology stack used to manage
Jenkins plugin Java dependencies were also changed.

[Jesse Glick]

Also +1 on Renovate for JS deps (at least unless and until Dependabot improves in this area) so long as Dependabot is retained for other (mainly Java) deps.