Tache3

.github/workflows/test.yml

@@ -1,37 +1,65 @@
-name: Maven tests
+name: Maven tests and coverage report with multiple JVM flags
 
 on:
   pull_request:
   push:
 
-jobs:
+jobs: 
   build:
     runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        jvm_flag:
+          - "-Xmx512m"
+          - "-XX:+AlwaysPreTouch"
+          - "-XX:+UseG1GC"
+          - "-XX:+UseStringDeduplication"
+          - "-XX:+UnlockExperimentalVMOptions -XX:+UseCompressedOops"
+
     steps:
-      - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
+      # Checkout the repository
+      - uses: actions/checkout@v4
+
+      # Set up JDK 17
       - name: Set up JDK 17
-        uses: actions/setup-java@6a0805fcefea3d4657a47ac4c165951e33482018 # v4
+        uses: actions/setup-java@v4
         with:
           java-version: '17'
           distribution: 'temurin'
           cache: maven
 
-      - name: Run Maven tests
-        run: mvn verify
+      # Sanitize the JVM flag for artifact names
+      - name: Sanitize JVM Flag
+        id: sanitize
+        run: |
+          sanitized_flag=$(echo "${{ matrix.jvm_flag }}" | sed 's/[:+]/_/g')
+          echo "sanitized_flag=$sanitized_flag" >> $GITHUB_ENV
 
-      - name: Get JaCoCo Coverage
-        id: coverage  
+      # Run Maven tests with different JVM flags and generate JaCoCo coverage report
+      - name: Run Maven tests with JVM Flag and generate coverage report
         run: |
-          coverage=$(python3 config/coverage.py target/site/jacoco/jacoco.csv) 
-          echo "COVERAGE=$coverage" >> $GITHUB_ENV
+          echo "Running tests with JVM flag: ${{ matrix.jvm_flag }}"
+          mvn clean verify
+        env:
+          JVM_OPTS: ${{ matrix.jvm_flag }}
+
+      # Upload JaCoCo Coverage Report as an artifact with sanitized name
+      - name: Upload JaCoCo Coverage Report
+        uses: actions/upload-artifact@v3
+        with:
+          name: jacoco-report-${{ env.sanitized_flag }}
+          path: target/site/jacoco/  # Path to the JaCoCo report
 
-      - name: Fail if coverage has not improved.
+      # Save test logs
+      - name: Save Test Logs
         run: |
-          coverage=$COVERAGE
-          threshold=81.58
-          if (( $(echo "$coverage - $threshold <= 0.1" | bc -l) )); then
-            echo "Coverage has not improved."
-            exit 1
-          else
-            echo "New coverage: $coverage%"
-          fi
+          mkdir -p logs
+          mv target/surefire-reports/*.txt logs/
+        if: always()
+
+      # Upload the logs as an artifact for each JVM flag with sanitized name
+      - name: Upload Test Logs
+        uses: actions/upload-artifact@v3
+        with:
+          name: test-logs-${{ env.sanitized_flag }}
+          path: logs/

documentation-tache3.md

@@ -0,0 +1,71 @@
+# Documentation des Flags JVM dans GitHub Actions
+
+## Introduction
+
+Dans ce projet, nous avons introduit plusieurs flags JVM dans le workflow GitHub Actions pour optimiser les performances, la gestion de la mémoire et l'efficacité des tests. L'objectif est de s'assurer que l'application est testée sous différentes configurations de mémoire et de gestion des ressources, afin d'améliorer la robustesse et la qualité des tests. Ce document explique chaque flag en détail, les raisons de leur choix, leurs impacts potentiels ainsi que la motivation derrière chaque sélection.
+
+> Parfois, notre JVM se prend pour une athlète olympique : prête à relever chaque défi de performance qu'on lui lance !
+
+## 1. Les Flags Utilisés
+
+Nous utilisons cinq flags différents pour tester notre application sous divers environnements. Pourquoi ? Parce qu’une JVM bien préparée est une JVM heureuse (et performante) ! 😄
+
+### `-Xmx512m`
+
+**Fonction :** Ce flag fixe la taille maximale de la mémoire du tas (heap) à 512 Mo.  
+**Motivation :** En limitant la mémoire disponible pour la JVM, nous simulons des environnements à faible mémoire, ce qui est essentiel pour vérifier si l’application peut fonctionner efficacement sous de telles contraintes. Cela aide à identifier les fuites de mémoire ou les inefficacités de gestion de mémoire.
+**Impact :** Ce réglage garantit que l’application peut tourner avec une mémoire limitée, ce qui est crucial pour une compatibilité avec des environnements de production aux ressources restreintes, améliorant ainsi la robustesse.
+
+> Oui, c’est un peu comme si on disait à la JVM de "faire des économies". Mais, une JVM économe est une JVM efficace !
+
+### `-XX:+AlwaysPreTouch`
+
+**Fonction :** Ce flag demande à la JVM d'allouer et de toucher la mémoire des pages du tas au démarrage.  
+**Motivation :** En activant cette option, la mémoire est initialisée dès le démarrage, réduisant les pauses futures dues à la montée en charge de la mémoire en cours d'exécution. Cela améliore l'expérience utilisateur en rendant les performances plus prévisibles.
+**Impact :** Ce flag permet d’améliorer la réactivité de l’application sous forte charge, garantissant des performances stables pendant les tests et renforçant la fiabilité.
+
+> C’est un peu comme s’assurer que toutes les chaises sont bien en place avant que le concert commence – la JVM évite ainsi toute distraction de dernière minute !
+
+### `-XX:+UseG1GC`
+
+**Fonction :** Utilise le ramasse-miettes G1 (Garbage First Garbage Collector), un collecteur de mémoire optimisé pour réduire les temps de pause.  
+**Motivation :** Le G1GC est conçu pour les applications nécessitant des pauses faibles et prédictibles. En le testant, nous évaluons la capacité de l'application à fonctionner avec un garbage collector moderne, idéal pour les applications intensives en mémoire.
+**Impact :** En réduisant la fréquence et la durée des pauses liées au ramasse-miettes, ce flag améliore l’observabilité et garantit des tests plus proches des conditions de production, surtout dans des environnements gourmands en ressources.
+
+> Le G1GC, c’est notre "super-héros de la mémoire" : toujours prêt à nettoyer discrètement, sans interrompre le spectacle !
+
+### `-XX:+UseStringDeduplication`
+
+**Fonction :** Ce flag active la déduplication des chaînes de caractères pour économiser de la mémoire en partageant les chaînes identiques.  
+**Motivation :** Les applications qui manipulent beaucoup de chaînes de caractères peuvent voir leur mémoire rapidement saturée. Ce flag économise de la mémoire en supprimant les doublons, ce qui est essentiel dans des environnements où l’optimisation des ressources est cruciale.
+**Impact :** La déduplication des chaînes améliore l’efficacité de l’application et garantit qu’elle reste stable même en cas de forte demande de mémoire pour les chaînes de caractères, optimisant ainsi la qualité et l’économie de mémoire.
+
+> Imaginez une bibliothèque où tous les livres en double sont fusionnés. Moins de livres, même savoir. La JVM fait pareil avec vos chaînes de caractères !
+
+### `-XX:+UnlockExperimentalVMOptions -XX:+UseCompressedOops`
+
+**Fonction :** Ce flag active des options expérimentales, notamment l'utilisation de pointeurs compressés, ce qui réduit la taille des pointeurs en mémoire.  
+**Motivation :** En activant ces options expérimentales, nous testons la compatibilité de l'application avec des fonctionnalités avancées de la JVM. Les pointeurs compressés permettent également une meilleure densité de mémoire, crucial pour les applications exécutées dans des environnements de faible mémoire.
+**Impact :** Ce flag réduit l'empreinte mémoire et permet de tester la performance de l’application dans des configurations plus avancées et évolutives, assurant ainsi sa future compatibilité avec des options JVM expérimentales.
+
+> C’est comme plier chaque bit pour qu’il prenne moins de place – on dirait de la magie, mais c’est juste la JVM qui devient plus "compacte" et efficace.
+
+## 2. Motivation des Choix
+
+Chaque flag a été soigneusement sélectionné pour couvrir différents aspects de performance et de gestion des ressources :
+
+1. **Robustesse des Tests** : Ces flags permettent de simuler des environnements variés, y compris des environnements de mémoire limitée ou des configurations avancées, garantissant ainsi une robustesse accrue de l’application face à des contraintes variées.
+
+2. **Optimisation des Ressources** : L’objectif est de vérifier que l’application utilise efficacement la mémoire et minimise les ressources nécessaires. Cette approche est cruciale pour garantir que l’application peut être exécutée sur des serveurs avec des capacités limitées tout en maintenant sa performance.
+
+3. **Préparation pour la Production** : En testant avec ces configurations, l’application est mieux préparée pour des environnements de production réels, où les ressources et les comportements de collecte de déchets peuvent varier.
+
+4. **Performance et Observabilité** : Les flags comme `-XX:+UseG1GC` et `-XX:+AlwaysPreTouch` aident à mieux comprendre comment l'application réagit à des stratégies avancées de gestion de la mémoire, optimisant ainsi l'expérience utilisateur en production.
+
+5. **Innovations et Expérimentations** : L’activation de `-XX:+UnlockExperimentalVMOptions` permet d'expérimenter avec des fonctionnalités avancées, garantissant que l’application est prête pour les nouvelles évolutions de la JVM, renforçant ainsi sa durabilité et sa flexibilité pour le futur.
+
+## Conclusion
+
+L'utilisation de ces cinq flags JVM dans le workflow GitHub Actions améliore la couverture des tests, assure la compatibilité avec divers environnements, et optimise les performances. En renforçant la robustesse, en améliorant l'observabilité et en optimisant l'utilisation des ressources, cette configuration garantit que notre application est prête pour les exigences de la production et les besoins futurs.
+
+Et, qui sait, peut-être que ces flags donneront même à la JVM un peu de caractère – après tout, on sait maintenant qu’elle aime être bien préparée, économe, et toujours prête à faire briller notre application !