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.
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.
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" ...
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.
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)
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 :Voir le pipeline complet pour cette branche
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
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/
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.
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.
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.
env:
FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
Cette solution transitoire est valable, mais qui reste dépendante de l'activité du mainteneurOption 2 — Installation manuelle de k6 (recommandée à long terme)
Au vue des faits, c'est la solution retenueMême si GitHub propose un opt-in temporaire via FORCE_JAVASCRIPT_ACTIONS_TO_NODE24
Cela ne constitue pas une solution pérenne.
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é.
- name: Setup k6
uses: grafana/setup-k6-action@v1
- 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
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)