How to Monitor Dependency Upgrades

Everytime we publish a new package version (e.g. @marfeel/core, @marfeel/cli) or a new docker image version (e.g. mfastly), we use Renovate and Serverless to update repositories that use this package or image as a dependency.

In order to monitor the update process we have created this dashboard (opens new window) and will explain shortly what you need to know about it.

The dashboard is showing a set timeframe (normally the last hour), which you can change to check past updates. E.g. if you had published a new version at 10:30 in the morning and wanted to check it in the afternoon, you could set the timeframe from 10:00 to 11:00 and you would see what Renovate did in that time range.

Renovate

Similar to Dependabot (opens new window), Renovate (opens new window) is a GitHub or CLI app that monitors your dependencies and opens Pull Requests when new ones are available.

The main advantage of Renovate is that it's extremely configurable (opens new window). It also gives the option to use a self-hosted (opens new window) version, which is key for Marfeel workflows to call it on demand.

Serverless

The Serverless Framework consists of an open source CLI and a hosted dashboard. Together, they provide you with full serverless application lifecycle management.

source: Serverless Framework Documentation (opens new window)

1. Dependency Updates and their versions

This data table tells us which dependencies are being updated and how many repositories are affected.

In this case we are updating the @marfeel/cli package to the version 1.0.1-snapshot.588 and this is affecting 410 repositories.

2. Update Progress and Timeline

The Status Pie and Status Timeline give us a quick overview of the status of shuttle.

We can see in the screenshot that around 14:15 we started some updates for a big amout of repositories, and that by the time we did the screenshot most of them had succeeded with their deployment.

3. Pending and Failed dependency updates

Once we have given Renovate some time to run through the updates, we'll use the Dependency Upgrades Table to address the upgrades that still have a pending or failure status.

To find them easily we have this detailed data table with the needed information to take actions.

In the screenshot:

1. Blue-Sky-Publications-Ltd-PRO: This dependency update has failed the deployment. We would have to go to that repository's Jenkins job and check what exactly went wrong and fix the possible issues.
2. Andrew-Manswell: This dependency update is still pending of deployment, and has a failed step. This means that the PR that runs before merging the update to master failed in a check run. In this case we would go to the PR and check why that check run failed.

If what happened and what action to take is not clear, please contact us in our slack channel #ask-marfeel-dx for help.

Re-triggering Renovate

There is a Jenkins Job (opens new window) where a user can force an event of a package published so Renovate tries to run again for all MediaGroups with that dependency.

This job receives the following parameters:

PARAMETER	Type	Default Value	Description
PACKAGE_NAME	string	core	Name of the package you want to trigger Renovate with
PACKAGE_VERSION	string	1.0.0-alpha.25016.25131	Package Version