Renovate your dependencies

Renovate your dependencies

Keeping track of multiple repositories is hard. Especially when it comes to the handling of outdated dependencies.

If you work with node.js you most likely have experienced the "fun" of updating dependencies. It even get worse if you don't do this regularly because then you are some major versions behind the latest one and the work to get your code base adjusted to those changes piles up.

Why should I update dependencies anyway?

If your application runs, it runs -  right? Why should you do the hassle and add additional effort in updating dependencies with features you might not need?
For the sake of security of course. Even if the top level dependencies don't have a security vulnerability, one of their sub-dependency could have one. That why it's so important to keep everything up to date.

It's also part of the OWASP Top 10 of Web Application Security Risks: A9:2017-Using Components with Known Vulnerabilities

Automate all the things

If you are a github user, you might have already heard of services like Greenkeeper, Snyk, Dependabot or Renovate. Those are all dedicated to keep dependencies up to date which is nice and you should enable them.

But if you work in a medium size/enterprise company it's very likely that you have to use an internally hosted Github/Gitlab version where those services are not allowed or accessible ... except Renovate 🚀
Renovate provides a Docker image which you can run inside the company CI/CD infrastructure.

At ShareNow we use a hosted Gitlab instance and the CI feature which makes it the perfect candidate for a Renovate integration.

Since Renovate is also published as executable npm module I decided to use this instead of the Docker image. We now have a separate Repository with a configuration file for Renovate an a CI configuration which looks like this:

before_script:
 - export DOCKER_IMAGE="$DOCKER_REGISTRY/$CI_PROJECT_NAME"
 - export DOCKER_IMAGE_TAG="$DOCKER_IMAGE:$CI_PIPELINE_ID"
 - export GITLAB_TOKEN=$GITLAB_TOKEN
 - export ARTIFACTORY_NPM_REGISTRY=$ARTIFACTORY_NPM_REGISTRY
 - export ARTIFACTORY_NPM_TOKEN=$ARTIFACTORY_NPM_TOKEN
 - export NPM_TOKEN=$ARTIFACTORY_NPM_TOKEN

stages:
- execute

renovate-execute:
  stage: execute
  image: node:12
  script:
    - echo $'\n' >> ~/.npmrc && echo "${ARTIFACTORY_NPM_REGISTRY}:_authToken=${ARTIFACTORY_NPM_TOKEN}" >> ~/.npmrc
    - npx renovate@stable
  tags:
    - some-runner-tag
.gitlab-ci.yml

In Gitlab it's possible to define schedules for pipelines. I created one to run every day at 4am on do the Renovate dependency check:

This works pretty well and we already merged more than 2200 merge requests across 37 projects 🚀

With great power comes great responsibility

Using a tool like Renovate requires a trust beforehand because this will have read and write access to your precious repositories. That's why I reviewed the renovate source code before I introduced it to our projects and it's also being used by some other popular companies (like Ghost) which adds also up on the trust bucket.

And the other risk is to have automated dependency updates of malicious code. That could also happen if someone is able to push malware in a formerly trusted dependency.

Whats next? More automation!

Currently it's parts of my morning routine to check the list of merge requests and merge them then. The problem is, that those merged dependencies got merged into master and then have to wait until someone creates a new release of that services.

My next goal might be to introduce semantic versioning which would allow automatic releases for all minor and patch versions where the pipeline succeeds and nothing breaks. But I'm still having some security concerns about that.

Show Comments