Change pattern proposal: Do automated instead of manual npm dependency updates
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
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)
- Move the renovate-gitlab-bot to be a GitLab project.
- Remove my private projects
- Set it up with GitLab Bot credentials
- 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?
- Total MRs: 93
- Average time to merge: 2.42 days
|Maintainer||Number of MRs||Percentage|
|Annabel Dunstone Gray||1||1.08%|
|Project||Number of MRs||Percentage|
|Pipelines||Number of MRs|