Change pattern proposal: Do automated instead of manual npm dependency updates

Old Pattern

Currently we update dependencies mostly manually. This has several downsides:

There is no direct responsible individual for dependency updates, so some updates are not done
Because we are not gradually updating dependencies, we often are multiple versions behind upstream, which means less features, less security and more pain updating to the latest version.
It also can be confusing that e.g. documentation in eslint / test utils are not matching with what we currently use

New Pattern

Since ~8 months (January 2019) I have been creating Merge Requests for @gitlab/ packages with the help of the renovate-gitlab-bot. As of this writing 167 Merge Requests updating dependencies have been created, 93 of which have been merged. Have a look at the statistics below for more fun insights.

It currently works like this:

On an hourly schedule:
   Check the defined projects and for each project: update(project)

update(project):
   check for updates in dependencies (currently only @gitlab/ scope)   
      if existing MR => Update MR;
      else
        create MR
        assign to @leipert

Essentially I am proposing the following Scheme:

Migration: (Same functionality as currently)
1. Move the renovate-gitlab-bot to be a GitLab project.
2. Remove my private projects
3. Set it up with GitLab Bot credentials
4. We need logic to add a milestone, unfortunately something that the renovate bot cannot do at the moment.

After that I want to update change the logic to the following:

update(project):
   check for an existing MR
      if the package is in the @gitlab/ scope
        if the pipeline is green => merge
        else: assign someone
   check for updates in dependencies (still only @gitlab/ scope)   
      if existing MR => Update MR
      else
        create MR

In the future I would like to broaden that scope with automatically updating other groups of packages. I would probably start with development dependencies like e.g. eslint / stylelint / jest / webpack. Because those should be rather safe to update and once they introduce failures, they should be more or less straight forward to fix. Next steps might be more modern dependencies (read: not jquery related stuff). We could also still use the old pattern of not-auto merging for them.

The cool thing is: Once a person pushes adds commits to a renovate created branch, that branch will be skipped, so actuall

Advantages of switching patterns

According to our stats, around 85% of the merged dependency updates created by the renovate bot had one to three pipelines. That means these are ones where no maintainer feedback was needed, and it was wasting time for me and the maintainer.
We get faster updates of our dependencies. Right now MRs with < 4 pipelines still took 2 days average to being merged.
Renovate actually gives nice diff views for the dependency updates. e.g.: https://app.renovatebot.com/package-diff?name=@gitlab%2fvisual-review-tools&from=1.0.1&to=1.0.2 that allow to review the diff of a dependency. So in case a dependency breaks, it's easy to check what actually changed

Disadvantages of switching patterns

Having a lot of MRs can be very noisy, this can be mitigated by having the automated MRs limited to one per project.
If an unreliable dependency is updated and the tests are not testing it sufficiently, we could end up with regressions.

What is the impact on our existing codebase?

Statistics:

Total MRs: 93
Average time to merge: 2.42 days

Maintainer distribution

Maintainer	Number of MRs	Percentage
Phil Hughes	13	13.98%
Clement Ho	34	36.56%
Fatih Acet	12	12.90%
Mike Greiling	8	8.60%
Tim Zallmann	2	2.15%
Kushal Pandya	17	18.28%
Filipa Lacerda	5	5.38%
Simon Knox	1	1.08%
Annabel Dunstone Gray	1	1.08%

Project distribution

Project	Number of MRs	Percentage
GitLab UI	13	13.98%
GitLab (CE/EE)	47	50.54%
design.gitlab.com	30	32.26%
GitLab SVGs	3	3.23%

Pipelines distribution

Pipelines	Number of MRs
1	47	50.54%
2	26	27.96%
3	7	7.53%
4	6	6.45%
5	2	2.15%
7	4	4.30%
8	1	1.08%