TP : Automatiser les mises à jour avec Renovate¶

Objectifs pédagogiques¶

À la fin de ce TP, vous devez être capables de :

comprendre le rôle de Renovate dans une démarche SCA
configurer un dépôt simple pour être pris en charge par Renovate
interpréter une PR d'onboarding et les premières PR de mise à jour
personnaliser un renovate.json de manière raisonnable
utiliser la Mend Renovate App comme mode de référence du TP
comprendre ce qu'une exécution autonome de Renovate vous oblige à gérer vous-mêmes

Fil conducteur¶

L'idée de ce TP est simple :

partir d'un petit dépôt avec quelques dépendances
laisser Renovate proposer les mises à jour
comprendre la différence entre onboarding, dashboard et PR
personnaliser le comportement
comprendre ce que la Mend Renovate App apporte directement, puis ce qu'il faut gérer soi-même si on en sort

Choix recommandé pour le projet¶

Pour aller vite, prenez un projet Node.js simple avec quelques dépendances volontairement anciennes

Exemple de dépendances intéressantes pour le TP :

express
axios
lodash
eslint

Le but n'est pas de créer une vraie application complexe, mais un dépôt suffisamment réaliste pour voir Renovate travailler

Partie 1 : Préparer un dépôt de démonstration¶

Objectif¶

Avoir un dépôt avec des dépendances détectables par Renovate

Travail demandé¶

Créez un petit projet, par exemple en Node.js

Exemple :

mkdir renovate-lab
cd renovate-lab
git init
npm init -y
npm install express@4.17.1 axios@0.21.1 lodash@4.17.20
npm install -D eslint@8.10.0

Ajoutez ensuite un commit initial et poussez le projet sur GitHub

Vérifications attendues¶

le dépôt existe sur GitHub
le fichier package.json contient plusieurs dépendances
certaines dépendances sont suffisamment anciennes pour que Renovate propose des mises à jour

Questions de synthèse¶

Pourquoi choisir volontairement quelques dépendances anciennes pour un TP
Pourquoi Renovate est-il plus utile sur un vrai dépôt versionné que sur un simple dossier local

Partie 2 : Découvrir Renovate avec la Mend Renovate App¶

Objectif¶

Comprendre l'expérience la plus simple d'utilisation de Renovate

Travail demandé¶

Installez la Mend Renovate App sur votre dépôt GitHub
Attendez la création de la PR d'onboarding
Lisez cette PR attentivement
Identifiez le fichier proposé par Renovate

Point d'attention¶

Dans ce TP, quand on parle du mode hébergé, on parle bien de la Mend Renovate App

C'est elle qui fournit l'expérience la plus naturelle sur GitHub pour :

l'installation sur un dépôt
l'onboarding
la gestion du Dependency Dashboard
la maintenance de la version du bot côté service hébergé

Point de repère¶

Lors de l'onboarding, Renovate propose souvent une configuration minimale de ce type :

{
  "extends": ["config:recommended"]
}

Ce que vous devez observer¶

Renovate ne modifie pas brutalement le dépôt sans démarrer par l'onboarding
la PR d'onboarding introduit la configuration de base
le Dependency Dashboard et les PR de mise à jour n'ont pas le même rôle
l'app hébergée gère pour vous l'authentification, l'installation GitHub App et le cycle d'exécution

Questions de synthèse¶

À quoi sert la PR d'onboarding
Quelle différence faites-vous entre la configuration config:recommended et une configuration totalement personnalisée
Quelle différence faites-vous entre une PR de mise à jour et le Dependency Dashboard
Pourquoi la Mend Renovate App est-elle plus simple à démarrer qu'une exécution self-hosted

Partie 3 : Personnaliser la configuration SaaS¶

Objectif¶

Comprendre comment adapter Renovate au rythme et aux règles d'une équipe

Travail demandé¶

Modifiez le renovate.json pour ajouter quelques règles simples

Exemple de base :

{
  "extends": ["config:recommended"],
  "labels": ["dependencies"],
  "dependencyDashboardApproval": true,
  "packageRules": [
    {
      "matchUpdateTypes": ["minor", "patch"],
      "automerge": false
    },
    {
      "matchDepTypes": ["devDependencies"],
      "labels": ["dev-dependencies"]
    }
  ]
}

Vous pouvez aussi ajouter une planification simple

Exemple :

{
  "schedule": ["after 9pm on sunday"]
}

Recommandation pédagogique¶

Restez sobres : 3 ou 4 règles maximum

Le but est de comprendre le sens de la configuration, pas de produire un renovate.json énorme

Ce que vous devez observer¶

les labels permettent de mieux classifier les PR
dependencyDashboardApproval rend les mises à jour plus contrôlées
les packageRules permettent de différencier les comportements selon le type de dépendance ou le type de mise à jour

Questions de synthèse¶

Pourquoi une équipe voudrait-elle approuver les mises à jour depuis le dashboard
Pourquoi l'automerge doit-il être utilisé avec prudence
Pourquoi séparer les dépendances de développement du reste peut être utile

Partie 4 : Lire les PR générées par Renovate¶

Objectif¶

Passer de la configuration à l'interprétation concrète des propositions de mise à jour

Travail demandé¶

Après l'onboarding et la configuration, observez les PR générées

Pour chaque PR, identifiez :

la dépendance concernée
la version actuelle
la version proposée
le type de mise à jour : patch, minor, major
le niveau de risque fonctionnel supposé

Ce que vous devez observer¶

toutes les mises à jour n'ont pas le même risque
une mise à jour majeure doit être traitée différemment d'une mise à jour patch
Renovate aide à industrialiser la maintenance, mais ne remplace pas le jugement humain

Questions de synthèse¶

Pourquoi une mise à jour majeure demande souvent plus de prudence
Pourquoi une stratégie "merge tout automatiquement" est risquée
Quel comportement proposeriez-vous pour patch, minor et major

Partie 5 : Exécuter Renovate en local (Mend Renovate CE) avec Docker, tunnel et GitLab¶

Objectif¶

Mettre en place l'édition communautaire auto-hébergée de Renovate (Mend Renovate Community Edition) en local, exposer son serveur de webhooks au public via un tunnel, et la connecter à votre projet GitLab pour réagir en temps réel aux événements

Étape 1 : Créer le Token d'accès (PAT) sur GitLab¶

Pour que Renovate puisse scanner votre projet, lire les dépendances et créer des Merge Requests, il a besoin d'un Personal Access Token (PAT) avec des privilèges appropriés

Allez sur GitLab dans les paramètres de votre compte : Preferences > Access Tokens (ou sur votre projet dans Settings > Access Tokens)
Créez un nouveau token avec le rôle Developer ou Maintainer
Cochez impérativement les scopes suivants :
- api
- read_repository
- write_repository
Copiez la valeur du token généré (nous l'utiliserons sous le nom MEND_RNV_GITLAB_PAT)

Étape 2 : Préparer et lancer le tunnel (ngrok ou cloudflared)¶

Comme notre instance Renovate CE va tourner sur notre machine locale (port 8080), nous devons l'exposer temporairement sur Internet pour recevoir les webhooks de GitLab

Option A : `ngrok`¶

Démarrez le tunnel pour le port 8080 :

ngrok http 8080

Notez l'URL HTTPS générée (ex: https://abcd-123.ngrok-free.app)

Option B : `cloudflared`¶

Démarrez le tunnel vers localhost :

cloudflared tunnel --url http://localhost:8080

Notez l'URL HTTPS générée (ex: https://abcd-123.trycloudflare.com)

Étape 3 : Configurer et démarrer Mend Renovate CE via Docker Compose¶

Créez un fichier docker-compose.yml dans votre dossier de travail local :

services:
  renovate-ce:
    image: ghcr.io/mend/renovate-ce:latest
    container_name: renovate-ce
    ports:
      - "8080:8080"
    environment:
      # Acceptation des conditions d'utilisation
      - MEND_RNV_ACCEPT_TOS=y

      # Clé de licence gratuite pré-enregistrée par Mend (limitation à 10 repositories maximum)
      - MEND_RNV_LICENSE_KEY=eyJsaW1pdCI6IjEwIn0=.30440220457941b71ea8eb345c729031718b692169f0ce2cf020095fd328812f4d7d5bc1022022648d1a29e71d486f89f27bdc8754dfd6df0ddda64a23155000a61a105da2a1

      # Configuration de la plateforme cible (GitLab)
      - MEND_RNV_PLATFORM=gitlab
      - MEND_RNV_ENDPOINT=https://gitlab.com/api/v4/
      - MEND_RNV_GITLAB_PAT=votre_token_gitlab_pat_ici # <--- REMPLACER ICI

      # Webhooks (Clé partagée avec GitLab pour sécuriser les appels)
      - MEND_RNV_WEBHOOK_SECRET=super-secret-renovate-token

      # Mode verbeux pour faciliter le debugging
      - LOG_LEVEL=debug
    restart: always

Lancez le conteneur en arrière-plan :

docker compose up -d

Suivez les logs pour vérifier que le serveur démarre correctement et écoute bien sur le port 8080 :

docker compose logs -f

Étape 4 : Configurer le Webhook sur votre dépôt GitLab¶

Nous devons maintenant configurer GitLab pour envoyer un signal à notre Renovate local dès qu'un changement survient

Rendez-vous sur votre dépôt GitLab
Allez dans Settings > Webhooks
Configurez les champs suivants :
- URL : Renseignez l'URL HTTPS de votre tunnel suivie de /webhook (ex: https://abcd-123.ngrok-free.app/webhook)
- Secret token : Entrez la même valeur que MEND_RNV_WEBHOOK_SECRET définie dans votre docker-compose.yml (super-secret-renovate-token)
- Trigger (Cochez les événements suivants) :
  - Push events (pour détecter les commits sur le projet)
  - Merge request events (pour réagir aux validations)
  - Issues events (nécessaire pour interagir avec le Dependency Dashboard)
Cliquez sur Add webhook
Testez la connexion via GitLab (Test > Push events). Vous devriez voir passer des logs debug dans la console de votre conteneur Docker

Étape 5 : Valider l'onboarding et interagir avec Renovate¶

Si le webhook fonctionne, Renovate va automatiquement démarrer un premier job sur votre dépôt
Il créera la Merge Request d'onboarding (contenant le fichier renovate.json initial)
Fusionnez (merge) cette MR
Renovate va alors créer le Dependency Dashboard (sous forme d'Issue sur GitLab) et commencera à générer des MRs pour mettre à jour vos dépendances obsolètes
Essayez de cocher une mise à jour sur le tableau de bord pour voir si votre conteneur local réagit instantanément grâce au webhook

Ce que vous devez observer¶

Renovate CE fonctionne en continu sous forme de serveur web et de workers
il réagit immédiatement aux actions de l'utilisateur grâce aux webhooks routés à travers le tunnel (ngrok/cloudflared)
vous devez gérer vous-mêmes le stockage, le cycle de vie du serveur et la sécurité (secrets, tokens)

Questions de synthèse¶

Quel est le rôle réel du tunnel dans cette architecture
En production dans une entreprise, comment remplacerait-on le tunnel pour assurer la pérennité du service
Quels sont les avantages et les inconvénients de cette approche self-hosted par rapport à la Mend Renovate App SaaS classique

Critères de réussite du TP¶

Le TP est réussi si vous pouvez démontrer :

un dépôt avec des dépendances correctement détectées
une PR d'onboarding comprise et expliquée
un renovate.json personnalisé mais simple
au moins une PR de mise à jour interprétée correctement
une exécution locale de Renovate liée à un dépôt GitLab
un tunnel local mis en place et compris dans son rôle

TP : Automatiser les mises à jour avec Renovate¶

Objectifs pédagogiques¶

Fil conducteur¶

Choix recommandé pour le projet¶

Partie 1 : Préparer un dépôt de démonstration¶

Objectif¶

Travail demandé¶

Vérifications attendues¶

Questions de synthèse¶

Partie 2 : Découvrir Renovate avec la Mend Renovate App¶

Objectif¶

Travail demandé¶

Point d'attention¶

Point de repère¶

Ce que vous devez observer¶

Questions de synthèse¶

Partie 3 : Personnaliser la configuration SaaS¶

Objectif¶

Travail demandé¶

Recommandation pédagogique¶

Ce que vous devez observer¶

Questions de synthèse¶

Partie 4 : Lire les PR générées par Renovate¶

Objectif¶

Travail demandé¶

Ce que vous devez observer¶

Questions de synthèse¶

Partie 5 : Exécuter Renovate en local (Mend Renovate CE) avec Docker, tunnel et GitLab¶

Objectif¶

Étape 1 : Créer le Token d'accès (PAT) sur GitLab¶

Étape 2 : Préparer et lancer le tunnel (ngrok ou cloudflared)¶

Option A : ngrok¶

Option B : cloudflared¶

Étape 3 : Configurer et démarrer Mend Renovate CE via Docker Compose¶

Étape 4 : Configurer le Webhook sur votre dépôt GitLab¶

Étape 5 : Valider l'onboarding et interagir avec Renovate¶

Ce que vous devez observer¶

Questions de synthèse¶

Critères de réussite du TP¶

Option A : `ngrok`¶

Option B : `cloudflared`¶