INFO PROJET

App Spring Boot : Flashcards - readme CI

Docker Image Hub

Qualité/couverture: SonarQube Cloud

L'objectif est de clarifier ce que mesure réellement la couverture de code, ainsi que ses limites.
Nous mettons en place "JaCoCo", configuré avec la génération de rapports (HTML/XML) et nous définissons le seuils de couverture en pilotant des exigences différentes, selon les branches via GitHub Actions. Enfin nous verrons comment intégrer "SonarCloud" tout en restant compatible avec les contraintes du plan gratuit

Essentiel dans une chaîne DevOps, l'intégration de JaCoCo (Java Code Coverage) dans un pipeline CI/CD répond à un objectif principal:

Mesurer et garantir la qualité du code de manière automatisée

Tests vs Couverture: deux notions différentes

La distinction est subtile mais importante: les tests sont l'action de vérifier, tandis que la couverture est la mesure de cette action

Et voici pourquoi il ne faut jamais viser "100%" de couverture comme objectif ultime

Concevoir des seuils progressifs (Ratchet / Clean as You Code)

Principes de seuils progressifs (Ratchet Effect)

L'idée n'est pas d'atteindre 80% partout, tout de suite, mais de ne jamais régresser

Seuil sur le "Nouveau Code"
On accepte une couverture globale faible (par exemple 30 %), mais on exige 80 % sur les lignes modifiées (diff coverage)
Ce principe est au cœur de la méthodologie "Clean as You Code" de SonarQube/SonarCloud

Clean as You Code & Effet cliquet (Ratched)

Seuils recommandés par branche (vérité CI/CD)

Des seuils progressifs sont appliqués via la CI, afin d'illustrer une approche réaliste en contexte professionnel

Configuration Maven JaCoCo (local & CI)

Intégration de jacoco-maven-plugin et sonar-maven-plugin

<properties>
  <jacoco.plugin.version>0.8.11</jacoco.plugin.version>
  <jacoco.check.skip>false</jacoco.check.skip>
  <jacoco.minimum.coverage>0.0</jacoco.minimum.coverage>
  //..
  <sonar.plugin.version>4.0.0.4121</sonar.plugin.version>
  <sonar.projectKey>val7304_flashcards</sonar.projectKey>
  <sonar.organization>val7304</sonar.organization>
  <sonar.projectName>flashcards</sonar.projectName>
  <sonar.coverage.exclusions>
      **/FlashcardsApplication.java,
      **/*Configuration.java,
      **/*Config.java,
      **/dto/**
  </sonar.coverage.exclusions>
  <sonar.coverage.jacoco.xmlReportPaths>${project.build.directory}/site/jacoco/jacoco.xml</sonar.coverage.jacoco.xmlReportPaths>
</properties>

<jacoco.minimum.coverage> sera surchargé par les pipelines (develop / staging / main)

<!-- JaCoCo -->
<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>${jacoco.plugin.version}</version>
    <executions>
        <!-- active agent -->
        <execution>
            <id>prepare-agent</id>
            <goals>
                <goal>prepare-agent</goal>
            </goals>
        </execution>
        //...  

<!-- HTML/XML -->
<execution>
    <id>report</id>
    <phase>verify</phase>
    <goals>
        <goal>report</goal>
    </goals>
</execution>

<!-- check -->
<execution>
    <id>jacoco-check</id>
    <phase>verify</phase>
    <goals>
        <goal>check</goal>
    </goals>
    <configuration>  

<!-- desactive localement: -Djacoco.check.skip=true -->
                <skip>${jacoco.check.skip}</skip>
                <rules>
                    <rule>
                        <element>BUNDLE</element>
                        <limits>
                            <limit>
                                <counter>LINE</counter>
                                <value>COVEREDRATIO</value>
                                <minimum>${jacoco.minimum.coverage}</minimum>
                            </limit>
                        </limits>
                    </rule>
                </rules>
            </configuration>
        </execution>
    </executions>
</plugin>

<!-- Sonar -->
<plugin>
    <groupId>org.sonarsource.scanner.maven</groupId>
    <artifactId>sonar-maven-plugin</artifactId>
    <version>4.0.0.4121</version>
</plugin>

Ajout de profils (Optionnel)

<profiles>
  <profile>
      <id>coverage-staging</id>
      <properties>
          <jacoco.minimum.coverage>0.70</jacoco.minimum.coverage>
      </properties>
  </profile>

  <profile>
      <id>coverage-main</id>
      <properties>
          <jacoco.minimum.coverage>0.80</jacoco.minimum.coverage>
      </properties>
  </profile>
</profiles>

./mvnw clean verify -Pcoverage-staging
./mvnw clean verify -Pcoverage-main

./mvnw clean verify -Djacoco.minimum.coverage=0.70
./mvnw clean verify -Djacoco.minimum.coverage=0.80 

Pas de fichier "sonar-project.properties"

Pipelines multi-branches avec GitHub Actions

La couverture de test doit être mesurée partout, mais imposée uniquement aux points de contrôle du cycle de vie applicatif

Runs des workflows par branches

- name: Run Maven clean verify
    run: ./mvnw -B clean verify jacoco:report

  - name: Upload JaCoCo report
    uses: actions/upload-artifact@v6
    with:
      name: jacoco-report
      path: target/site/jacoco/
  

- name: Verify Coverage 70%
  run: ./mvnw -B clean verify jacoco:report -Djacoco.minimum.coverage=0.70

- name: Upload JaCoCo artifacts
  uses: actions/upload-artifact@v6
  with:
    name: jacoco-report
    path: |
      target/site/jacoco/index.html
      target/site/jacoco/jacoco.xml

./mvnw clean verify 
  -Djacoco.minimum.coverage=0.70

./mvnw clean verify -Pcoverage-staging

- name: Build + Tests + Coverage gate (release)
  if: env.IS_RELEASE == 'true'
  run: ./mvnw -B clean verify -Djacoco.minimum.coverage=0.80

- name: Build + Unit tests only (non-release)
  if: env.IS_RELEASE != 'true'
  run: ./mvnw -B clean test jacoco:report

- name: Upload JaCoCo XML
  uses: actions/upload-artifact@v6
  with:
    name: jacoco-xml
    path: target/site/jacoco/jacoco.xml

- name: SonarCloud analysis
  if: github.ref == 'refs/heads/main'
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
  run: >
    ./mvnw sonar:sonar
    -Dsonar.host.url=https://sonarcloud.io
    -Dsonar.organization=val7304
    -Dsonar.projectKey=${{ secrets.SONAR_PROJECT_KEY }}
    -Dsonar.qualitygate.wait=true

./mvnw clean verify 
  -Djacoco.minimum.coverage=0.80

./mvnw clean verify -Pcoverage-main

Utiliser SonarCloud (Free Plan) avec JaCoCo

Avec le plan gratuit SonarCloud, on ne peux analyser qu'une seule branche “complète”: la branche principale.
Les autres branches (develop, staging, feature/…) sont visibles via les analyses de Pull Requests vers cette branche

Sur [main]: Chaque scan met à jour la base de référence (couverture, bugs, vulnérabilités, dette) du projet
Sur [develop] & [staging]: On analyse via des PR (vers main) et on voit la couverture et la qualité sur le "nouveau code" de ces branches

Configuration CI/CD

Exemple de logique

Commande type pour une PR

mvn sonar:sonar \
  -Dsonar.projectKey=YOUR_PROJET \
  -Dsonar.organization=YOUR_ORG \
  -Dsonar.host.url=https://sonarcloud.io \
  -Dsonar.cache.enabled=true \
  -Dsonar.coverage.jacoco.xmlReportPaths=target/site/jacoco/jacoco.xml

Relation JaCoCo et SonarCloud (Free Plan)

→ En local: On peut ouvrir le rapport et voir ainsi la couverture détaillée de toutes les classes
→ Sur une PR: SonarCloud nous montre si les nouvelles lignes sont couvertes par des tests
     Si on ajoute 10 lignes, Sonar analyse la couverture du “New Code” définie par la branche cible et compare les métriques au Quality Gate.
→ Sur main: après le merge, une analyse complète met à jour la couverture globale et les métriques de qualité du projet

Limitations importantes du Free Plan

Visualisation pour Develop/Staging

• Via PR: Gardez une PR ouverte de develop vers main. Chaque push sur develop mettra à jour l'onglet "Checks" de la PR avec la couverture SonarCloud
• Rapports locaux/CI: Consultez directement le fichier target/site/jacoco/ généré en local et, dans les artefacts de la CI pour voir la couverture totale de la branche sans passer par SonarCloud

Conclusion

La couverture comme contrat qualité

En pratique, JaCoCo vous donne une mesure factuelle des zones non testées, là où SonarCloud fournit la vue d'ensemble (bugs, vulnérabilités, dette)

• La CI orchestre ces outils pour transformer la couverture en contrat qualité: Pas de régression - Pas de code non testé qui passe en production
• Commencez simple (seuil global bas, seuil élevé sur le nouveau code), puis durcissez progressivement les règles sur staging et main au rythme de l'équipe
• L'objectif n'est pas d'afficher 100% de couverture, mais de livrer du code fiable, soutenu par des tests pertinents

Dans l'article suivant, nous verrons comment poser les bases (branche unique) pour un premier pipeline (main)