Maximize Page
Tech & DevOps HubEspace Tech & DevOps: Explorez le monde du Dev, du Cloud et des outils DevOps à travers nos articles et discussions Explore the world of development, the cloud and DevOps tools

UPDATE - Modification du workflow staging

Date de l'article:13-04-2026
Grafana CI/CD Github-Actions UPDATE
Annexe présentant une évolution du pipeline staging initial afin de tester une image dans des conditions proches de la production. L'application n'est plus exécutée via un simple JAR, mais à travers une image Docker

Cette annexe présente une évolution du pipeline staging initial.
Nous allons modifier deux jobs dans le workflow staging, dont l'objectif est de se rapprocher d'un comportement réel de production, en introduisant une exécution conteneurisée, tout en conservant les garanties de qualité, de sécurité et de reproductibilité mises en place précédemment.


Contexte des 2 jobs
1 Le job "functional-tests"

En testant l'image avant son déploiement en production, on s'assure que le code fonctionne non seulement en isolation, mais également une fois empaqueté dans son conteneur, avec ses dépendances système et son environnement d'exécution réels.

Pourquoi c'est important ?

Le comportement d'une application peut différer une fois conteneurisée : les dépendances système, les images de base et la configuration runtime introduisent des risques non négligeables. La sécurité doit donc être validée au niveau de l'image finale, et non uniquement au niveau du code source.

Cette approche permet de valider non seulement le code, son packaging, son environnement d'exécution et son comportement dans des conditions proches de la production.

Voir les étapes de modification

2 Le job "load-test"

Un Warning est apparu sur le job lors du dernier build:

"Node.js 20 actions are deprecated. 
The following actions are running on Node.js 20 and may not work 
as expected: grafana/setup-k6-action@v1"  ...
GitHub annonce :
Juin 2026 → bascule automatique vers Node.js 24
Septembre 2026 → suppression définitive de Node.js 20 des runners

Il s'agit d'un risque réel, le job pourrait soit échouer brutalement après la migration, soit présenter des comportements inattendus difficiles à diagnostiquer en cours de pipeline. Nous allons procéder par étapes pour choisir la solution la plus robuste et la plus pérenne possible.

Le pipeline staging devient ainsi une zone de validation réaliste et complète avant la mise en production.


Modification des étapes du pipeline staging
   LÉGENDE :

Déjà dans le pipeline (staging)
 CI de base
 CI de base (modifié)
 CI de base (supprimé)
 Ajout spécial (staging/main)
 Artefacts (upload/download)


[staging] reprenait déjà 100 % des étapes de base (develop)

Checkout code
Set up JDK 17
Make mvnw executable
Check formatting (Spotless)
Initialize CodeQL
Run Tests — Maven clean verify
Upload artifact
Perform CodeQL analysis
Scan filesystem with Trivy

Évolutions apportées au job "build-test-static-analysis"

Le job build-test-static-analysis upload l'artefact (app.jar), disponible pour être réutilisé dans les jobs suivants (partage inter-jobs).

Dans ce job, plusieurs nouvelles étapes viennent enrichir le pipeline :
L'image est construite avec le tag flashcards:staging, puis scannée avec Trivy afin de détecter d'éventuelles vulnérabilités.
L'application est ensuite lancée dans un conteneur Docker isolé.
Sa santé est vérifiée via l'endpoint /actuator/health, garantissant que :
  • le conteneur démarre correctement,
  • l'application est opérationnelle,
  • la connectivité avec la base de données est fonctionnelle.
Ces évolutions permettent de valider une chaîne complète de delivery: build → packaging → sécurité → exécution → validation fonctionnelle → observabilité.
Modification du job "functional-tests"

Voir le pipeline complet pour cette branche

Modification des étapes du workflow

Certaines étapes existaient déjà. Nous allons en supprimer, en modifier et en ajouter d'autres pour coller au nouveau fonctionnement conteneurisé.
Je rappelle que le dépôt GitHub reste la source de vérité en cas de divergence liée aux mises à jour CI/CD.

steps:
  - name: Checkout code
  - name: Download application JAR

  - name: Copy JAR to target
    run: |
      mkdir -p target
      cp app-jar/*.jar target/

  - name: Wait for PostgreSQL

  - name: Build Docker image
    run: docker build -t flashcards:staging .

  - name: Install Trivy (official repo)
  - name: Scan Docker image (Trivy - conditional)

  - name: Run container
    run: >
      docker run -d --name flashcards-staging \
        --add-host=host.docker.internal:host-gateway \
        -p 8081:8081 \
        -e SPRING_PROFILES_ACTIVE=staging \
        -e SPRING_DATASOURCE_URL=jdbc:postgresql://host.docker.internal:5432/flashcardsdb \
        -e SPRING_DATASOURCE_USERNAME=postgres \
        -e SPRING_DATASOURCE_PASSWORD=${{ github.actor == 'dependabot[bot]' && 'postgres' || secrets.POSTGRES_PASSWORD }} \
        flashcards:staging

  - name: Wait for healthcheck
    run: |
      for i in {1..30}; do
        if curl -sf http://localhost:8081/actuator/health | grep UP > /dev/null; then
          echo "Container healthy"
          exit 0
        fi
        sleep 2
      done

      echo "Container failed to start"
      docker logs flashcards-staging
      exit 1

  - name: Set up Node.js (for Newman) # jusqu'à l'étape : Upload Newman reports

  - name: Save container logs
    if: always()
    run: |
      if docker ps -a --format '{{.Names}}' | grep -q flashcards-staging; then
        docker logs flashcards-staging > container.log
      else
        echo "Container not found" > container.log
      fi

  # On remplace l'upload des logs Spring Boot par les logs du conteneur Docker
  - name: Upload container logs
    if: always()
    uses: actions/upload-artifact@v6
    with:
      name: container-logs
      path: container.log

  # On remplace l'arrêt de Spring Boot par l'arrêt du conteneur
  - name: Stop container
    if: always()
    run: |
      docker stop flashcards-staging || true
      docker rm flashcards-staging || true
Les étapes du job:
Checkout code
Download application JAR
- name: Copy JAR to target
  Prépare un dossier target et y dépose le .jar
  Nécessaire avant la création de l'image Docker
Wait for Postgress
- name: Build Docker image
Crée une image nommée flashcards:staging
Étapes modifiées
Cliquez sur l'image pour voir les détails
Install Trivy (official repo)
Scan Docker image (Trivy - conditional)

Suppression des étapes
Set up JDK 17
Start Spring Boot
Remplacées par:
- name: Run container
  Lance le conteneur en mode détaché et   injecte des variables d'environnement (profil, accès à la base)
- name: Wait for healthcheck
  Boucle à 30 tentatives (max)
  l'appel d'URL /actuator/health
CI de base
Set up Node.js
Install Newman
Run API Tests - Functional & Error cases
Upload Newman JUnit reports
- name: Save container logs
  Extrait les logs du conteneur Docker
On remplace
Upload Spring Boot logs
Stop Spring Boot
par:
- name: Upload container logs
  "container-logs" - 1.93 KB
- name: Stop container

Investigation et résolution du job k6
Contexte — Warning sur le job "load-test"
WARNING
Node.js 20 actions are deprecated. The following actions are running on Node.js 20 and may not work as expected:
  grafana/setup-k6-action@ffe7d7290dfa715e48c2ccc924d068444c94bde2

Actions will be forced to run with Node.js 24 by default starting June 2nd, 2026.
Node.js 20 will be removed from the runner on September 16th, 2026.

Please check if updated versions of these actions are available that support Node.js 24.
To opt into Node.js 24 now, set the FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true environment variable on the runner or in your workflow file.
Once Node.js 24 becomes the default, you can temporarily opt out by setting ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true.

For more information see: https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/

Étapes de vérification — Les faits
FAIT 1

Le SHA actuel (mis à jour par Dependabot) : ffe7d7290dfa715e48c2ccc924d068444c94bde2 pointe bien vers la v1.1.0 de l'action. Au moment ou j'écrivais ces ligne, le tag pointait encore vers le runtime interne node20 .node-version.

FAIT 2

L'action Grafana est répertoriée dans les mises à jour bloquées des dépendances Dependabot : setup-k6-action/issues/22. Il est donc probable qu'aucune mise à jour ne soit publiée rapidement.

UPDATE: 28/04

Bien qu'une migration vers Node.js 24 soit en cours côté action officielle, l'installation manuelle reste une approche plus fiable pour garantir la reproductibilité et éviter toute dépendance au cycle de release des actions tierces.


Solutions envisagées
Les différentes options
Option 1 — Ignorer (recommandé à court terme)
La solution la plus pragmatique. Aucun effort, aucun risque immédiat : le warning est informatif jusqu'en juin 2026. On attend une mise à jour de l'action upstream. Dans le même temps: Surveiller une nouvelle release Grafana
Combiner:
env: 
  FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
Cette solution transitoire est valable, mais qui reste dépendante de l'activité du mainteneur

Option 2 — Installation manuelle de k6 (recommandée à long terme)

Au vue des faits, c'est la solution retenue
Raisonnement

Même si GitHub propose un opt-in temporaire via FORCE_JAVASCRIPT_ACTIONS_TO_NODE24
Cela ne constitue pas une solution pérenne.

En réalité; cela ne fait que retarder le problème.

On s'apperçoit que les GitHub Actions tierces ne suivent pas toujours
     le rythme des évolutions de la plateforme

À un certain niveau de maturité DevOps, il est préférable soit
     de forker l'action, soit de la remplacer par des scripts maîtrisés

Dans un pipeline CI/CD avancé (intégrant Trivy, CodeQL, etc.), les actions "boîte noire" introduisent un manque de visibilité et un risque d'auditabilité.


Remplacement de l'étape
Ancienne installation (dépréciée)
- name: Setup k6
  uses: grafana/setup-k6-action@v1
Nouvelle installation (manuelle et épinglée)
- name: Install k6 (pinned)
  run: |
    K6_VERSION="0.49.0"

    sudo apt-get update
    sudo apt-get install -y wget gnupg

    wget -qO - https://dl.k6.io/key.gpg | \
      gpg --dearmor | \
      sudo tee /usr/share/keyrings/k6-archive-keyring.gpg > /dev/null

    echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] \
      https://dl.k6.io/deb stable main" | \
      sudo tee /etc/apt/sources.list.d/k6.list

    sudo apt-get update

    if apt-cache madison k6 | grep -q "$K6_VERSION"; then
      sudo apt-get install -y k6=$K6_VERSION
    else
      echo "[ERROR] k6 version $K6_VERSION not found"
      apt-cache madison k6
      exit 1
    fi
Avantages de l'installation manuelle
Aucune dépendance externe — plus de risque de breaking change lié à une action tierce
Version épingléeK6_VERSION="0.49.0" garantit une reproductibilité parfaite d'un run à l'autre
Zéro warning Node.js — on installe via apt, aucun runtime JavaScript impliqué
Contrôle total — on sait exactement ce qui est installé, comment et depuis où
Pipeline plus stable — une modification chez le mainteneur de l'action n'affecte plus votre pipeline
Meilleure auditabilité — chaque étape est lisible, traçable et versionnée directement dans le workflow

On gagne en reproductibilité, en sécurité et en autonomie, sans aucune contrepartie fonctionnelle

Ces évolutions rapprochent significativement le pipeline staging d'un environnement de production réel, en validant l'application dans son artefact final (image Docker) plutôt que sous forme isolée (JAR)


Laissez-moi un commentaire

En postant un commentaire anonyme, vous adhérez automatiquement aux conditions d'utilisation du site.