doc-locale/fr-fr/ci/testing/code_quality.md
{{< details >}}
{{< /details >}}
La qualité du code identifie les problèmes de maintenabilité avant qu'ils ne deviennent une dette technique. Les retours automatisés fournis lors des revues de code peuvent aider votre équipe à écrire un meilleur code. Les résultats apparaissent directement dans les merge requests, rendant les problèmes visibles au moment où il est le plus rentable de les corriger.
La qualité du code fonctionne avec plusieurs langages de programmation et s'intègre aux linters, vérificateurs de style et analyseurs de complexité courants. Vos outils existants peuvent alimenter le workflow de qualité du code, préservant ainsi les préférences de votre équipe tout en standardisant l'affichage des résultats.
Différentes fonctionnalités sont disponibles selon les éditions GitLab, comme indiqué dans le tableau suivant :
| Fonctionnalité | Dans Free | Dans Premium | Dans Ultimate |
|---|---|---|---|
| Importer les résultats de qualité du code depuis des jobs CI/CD | {{< yes >}} | {{< yes >}} | {{< yes >}} |
| Utiliser l'analyse basée sur CodeClimate | {{< yes >}} | {{< yes >}} | {{< yes >}} |
| Voir les résultats dans les rapports de merge request | {{< yes >}} | {{< yes >}} | {{< yes >}} |
| Voir les résultats dans un rapport de pipeline | {{< no >}} | {{< yes >}} | {{< yes >}} |
| Voir les résultats dans la vue des modifications de la merge request | {{< no >}} | {{< no >}} | {{< yes >}} |
| Analyser l'état général dans une vue récapitulative de la qualité du projet | {{< no >}} | {{< no >}} | {{< yes >}} |
La qualité du code est un système ouvert qui prend en charge l'importation des résultats de nombreux outils d'analyse. Pour détecter les violations et les faire remonter, vous pouvez :
Vous pouvez capturer les résultats de plusieurs outils dans un seul pipeline. Par exemple, vous pouvez exécuter un linter de code pour analyser votre code ainsi qu'un linter de langage pour analyser votre documentation, ou utiliser un outil autonome conjointement à une analyse basée sur CodeClimate. La qualité du code combine tous les rapports afin que vous les voyiez tous lorsque vous consultez les résultats.
De nombreuses équipes de développement utilisent déjà des linters, des vérificateurs de style ou d'autres outils dans leurs pipelines CI/CD pour détecter automatiquement les violations des normes de codage. Vous pouvez faciliter la visualisation et la correction des résultats de ces outils en les intégrant à la qualité du code.
Pour vérifier si votre outil dispose déjà d'une intégration documentée, consultez Intégrer des outils courants avec la qualité du code.
Pour intégrer un autre outil à la qualité du code :
codequality correspondant à ce fichier.Désormais, après l'exécution du pipeline, les résultats de l'outil de qualité sont traités et affichés.
[!warning] Cette fonctionnalité a été dépréciée dans GitLab 17.3 et sa suppression est prévue dans la version 19.0. Intégrez directement les résultats d'un outil pris en charge à la place.
La qualité du code inclut également un template CI/CD intégré, Code-Quality.gitlab-ci.yaml. Ce template exécute une analyse basée sur le moteur d'analyse open source CodeClimate.
Le moteur CodeClimate exécute :
Pour plus de détails, consultez Configurer l'analyse de qualité du code basée sur CodeClimate.
Le moteur CodeClimate utilise un ensemble personnalisable de plugins d'analyse. Certains sont activés par défaut ; d'autres doivent être explicitement activés. Les intégrations suivantes sont disponibles pour remplacer les plugins intégrés :
| Plugin | Activé par défaut | Remplacement |
|---|---|---|
| Duplication | {{< yes >}} | Intégrer PMD Copy/Paste Detector. |
| ESLint | {{< yes >}} | Intégrer ESLint. |
| gofmt | {{< no >}} | Intégrer golangci-lint et activer le linter gofmt. |
| golint | {{< no >}} | Intégrer golangci-lint et activer l'un des linters inclus qui remplace golint. golint est déprécié et figé. |
| govet | {{< no >}} | Intégrer golangci-lint. golangci-lint inclut govet par défaut. |
| markdownlint | {{< no >}} (pris en charge par la communauté) | Intégrer markdownlint-cli2. |
| pep8 | {{< no >}} | Intégrez un linter Python alternatif tel que Flake8, Pylint ou Ruff. |
| RuboCop | {{< yes >}} | Intégrer RuboCop. |
| SonarPython | {{< no >}} | Intégrez un linter Python alternatif tel que Flake8, Pylint ou Ruff. |
| Stylelint | {{< no >}} (pris en charge par la communauté) | Intégrer Stylelint. |
| SwiftLint | {{< no >}} | Intégrer SwiftLint. |
Les résultats de qualité du code sont affichés dans :
Les résultats de l'analyse de la qualité du code s'affichent dans l'onglet Rapports de la merge request. Plusieurs résultats de qualité du code ayant des empreintes identiques s'affichent comme une seule entrée.
Pour plus d'informations, consultez les rapports de merge request.
{{< details >}}
{{< /details >}}
Les résultats de qualité du code s'affichent dans la vue Modifications de la merge request. Les lignes contenant des problèmes de qualité du code sont marquées par un symbole à côté de la marge. Sélectionnez le symbole pour afficher la liste des problèmes, puis sélectionnez un problème pour en afficher les détails.
{{< details >}}
{{< /details >}}
La liste complète des violations de qualité du code générées par un pipeline est affichée dans l'onglet Qualité du code de la page de détails du pipeline. La vue détaillée du pipeline affiche tous les résultats de qualité du code trouvés sur la branche sur laquelle il a été exécuté.
{{< details >}}
{{< /details >}}
{{< history >}}
project_quality_summary_page. Cette fonctionnalité est en bêta. Désactivé par défaut.{{< /history >}}
La vue de la qualité du projet affiche une vue d'ensemble des résultats de qualité du code. La vue est accessible sous Analyse > Données d'analyse CI/CD, et nécessite que le feature flag project_quality_summary_page soit activé pour ce projet particulier.
Vous pouvez importer les résultats de qualité du code depuis n'importe quel outil capable de générer un rapport dans le format suivant. Ce format est une version du format de rapport CodeClimate qui inclut un nombre réduit de champs.
Le fichier que vous fournissez en tant qu'artefact de rapport de qualité du code doit contenir un tableau JSON unique. Chaque objet de ce tableau doit posséder au minimum les propriétés suivantes :
| Nom | Type | Description |
|---|---|---|
description | Chaîne | Une description lisible par l'humain de la violation de qualité du code. |
check_name | Chaîne | Un nom unique représentant la vérification, ou la règle, associée à cette violation. |
fingerprint | Chaîne | Une empreinte unique pour identifier cette violation de qualité du code spécifique, par exemple un hachage de son contenu. |
location.path | Chaîne | Le fichier contenant la violation de qualité du code, exprimé sous forme de chemin relatif dans le dépôt. Ne pas préfixer avec ./. |
location.lines.begin ou location.positions.begin.line | Entier | La ligne sur laquelle la violation de qualité du code s'est produite. |
severity | Chaîne | La gravité de la violation, qui peut être l'une des valeurs suivantes : info, minor, major, critical ou blocker. |
Le format diffère du format de rapport CodeClimate de la manière suivante :
Par exemple, voici un rapport conforme :
[
{
"description": "'unused' is assigned a value but never used.",
"check_name": "no-unused-vars",
"fingerprint": "7815696ecbf1c96e6894b779456d330e",
"severity": "minor",
"location": {
"path": "lib/index.js",
"lines": {
"begin": 42
}
}
}
]
De nombreux outils prennent nativement en charge le format de rapport requis pour intégrer leurs résultats à la qualité du code. Ils peuvent l'appeler « rapport CodeClimate », « rapport GitLab Code Quality » ou un autre nom similaire.
D'autres outils peuvent être configurés pour créer une sortie JSON en fournissant un template personnalisé ou une spécification de format. Étant donné que le format de rapport ne comporte que quelques champs obligatoires, vous pourrez peut-être utiliser ce type de sortie pour créer un rapport de qualité du code.
Si vous utilisez déjà un outil dans votre pipeline CI/CD, vous devriez adapter le job existant pour y ajouter un rapport de qualité du code. L'adaptation du job existant vous évite d'exécuter un job séparé qui pourrait dérouter les développeurs et allonger la durée d'exécution de vos pipelines.
Si vous n'utilisez pas encore d'outil, vous pouvez écrire un job CI/CD de toutes pièces ou adopter l'outil en utilisant un composant CI/CD du catalogue CI/CD.
Si vous avez déjà un job ESLint dans vos pipelines CI/CD, vous devriez ajouter un rapport pour envoyer sa sortie vers la qualité du code. Pour intégrer sa sortie :
eslint-formatter-gitlab comme dépendance de développement dans votre projet.--format gitlab à la commande que vous utilisez pour exécuter ESLint.codequality qui pointe vers l'emplacement du fichier de rapport.
ESLINT_CODE_QUALITY_REPORT sur le nom de fichier spécifié pour votre artefact, tel que gl-code-quality-report.json.Vous pouvez également utiliser ou adapter le composant CI/CD ESLint pour exécuter l'analyse et intégrer sa sortie à la qualité du code.
Si vous avez déjà un job Stylelint dans vos pipelines CI/CD, vous devriez ajouter un rapport pour envoyer sa sortie vers la qualité du code. Pour intégrer sa sortie :
@studiometa/stylelint-formatter-gitlab comme dépendance de développement dans votre projet.--custom-formatter=@studiometa/stylelint-formatter-gitlab à la commande que vous utilisez pour exécuter Stylelint.codequality qui pointe vers l'emplacement du fichier de rapport.
STYLELINT_CODE_QUALITY_REPORT sur le nom de fichier spécifié pour votre artefact, tel que gl-code-quality-report.json.Pour plus de détails et un exemple de définition de job CI/CD, consultez la documentation de @studiometa/stylelint-formatter-gitlab.
Si vous avez déjà un job MyPy dans vos pipelines CI/CD, vous devriez ajouter un rapport pour envoyer sa sortie vers la qualité du code. Pour intégrer sa sortie :
Installez mypy-gitlab-code-quality comme dépendance dans votre projet.
Modifiez votre commande mypy pour envoyer sa sortie vers un fichier.
Ajoutez une étape au script de votre job pour retraiter le fichier dans le format requis en utilisant mypy-gitlab-code-quality. Par exemple :
- mypy $(find -type f -name "*.py" ! -path "**/.venv/**") --no-error-summary > mypy-out.txt || true # "|| true" is used for preventing job failure when mypy find errors
- mypy-gitlab-code-quality < mypy-out.txt > gl-code-quality-report.json
Déclarez un artefact de rapport codequality qui pointe vers l'emplacement du fichier de rapport.
Vous pouvez également utiliser ou adapter le composant CI/CD MyPy pour exécuter l'analyse et intégrer sa sortie à la qualité du code.
Si vous avez déjà un job Flake8 dans vos pipelines CI/CD, vous devriez ajouter un rapport pour envoyer sa sortie vers la qualité du code. Pour intégrer sa sortie :
flake8-gl-codeclimate comme dépendance dans votre projet.--format gl-codeclimate --output-file gl-code-quality-report.json à la commande que vous utilisez pour exécuter Flake8.codequality qui pointe vers l'emplacement du fichier de rapport.Vous pouvez également utiliser ou adapter le composant CI/CD Flake8 pour exécuter l'analyse et intégrer sa sortie à la qualité du code.
Si vous avez déjà un job Pylint dans vos pipelines CI/CD, vous devriez ajouter un rapport pour envoyer sa sortie vers la qualité du code. Pour intégrer sa sortie :
pylint-gitlab comme dépendance dans votre projet.--output-format=pylint_gitlab.GitlabCodeClimateReporter à la commande que vous utilisez pour exécuter Pylint.pylint pour envoyer sa sortie vers un fichier.codequality qui pointe vers l'emplacement du fichier de rapport.Vous pouvez également utiliser ou adapter le composant CI/CD Pylint pour exécuter l'analyse et intégrer sa sortie à la qualité du code.
Si vous avez déjà un job Ruff dans vos pipelines CI/CD, vous devriez ajouter un rapport pour envoyer sa sortie vers la qualité du code. Pour intégrer sa sortie :
--output-format=gitlab à la commande que vous utilisez pour exécuter Ruff.ruff check pour envoyer sa sortie vers un fichier.codequality qui pointe vers l'emplacement du fichier de rapport.Vous pouvez également utiliser ou adapter l'intégration GitLab CI/CD Ruff documentée pour exécuter l'analyse et intégrer sa sortie à la qualité du code.
Si vous avez déjà un job golangci-lint dans vos pipelines CI/CD, vous devriez ajouter un rapport pour envoyer sa sortie vers la qualité du code. Pour intégrer sa sortie :
Ajoutez les arguments à la commande que vous utilisez pour exécuter golangci-lint.
--out-format code-climate:gl-code-quality-report.json,line-number.--output.code-climate.path=gl-code-quality-report.json.Déclarez un artefact de rapport codequality qui pointe vers l'emplacement du fichier de rapport.
Vous pouvez également utiliser ou adapter le composant CI/CD golangci-lint pour exécuter l'analyse et intégrer sa sortie à la qualité du code.
Le PMD Copy/Paste Detector (CPD) nécessite une configuration supplémentaire car sa sortie par défaut n'est pas conforme au format requis.
Vous pouvez utiliser ou adapter le composant CI/CD PMD pour exécuter l'analyse et intégrer sa sortie à la qualité du code.
L'utilisation de SwiftLint nécessite une configuration supplémentaire car sa sortie par défaut n'est pas conforme au format requis.
Vous pouvez utiliser ou adapter le composant CI/CD Swiftlint pour exécuter l'analyse et intégrer sa sortie à la qualité du code.
L'utilisation de RuboCop nécessite une configuration supplémentaire car sa sortie par défaut n'est pas conforme au format requis.
Vous pouvez utiliser ou adapter le composant CI/CD RuboCop pour exécuter l'analyse et intégrer sa sortie à la qualité du code.
L'utilisation de Roslynator nécessite une configuration supplémentaire car sa sortie par défaut n'est pas conforme au format requis.
Vous pouvez utiliser ou adapter le composant CI/CD Roslynator pour exécuter l'analyse et intégrer sa sortie à la qualité du code.
Vous pouvez utiliser la qualité du code pour analyser n'importe quel fichier stocké dans un dépôt, même s'il ne s'agit pas de code.
Si vous avez déjà un job Vale dans vos pipelines CI/CD, vous devriez ajouter un rapport pour envoyer sa sortie vers la qualité du code. Pour intégrer sa sortie :
gitlab-ci-utils de la communauté. Ce projet communautaire fournit également une image de conteneur préconfigurée qui inclut le même template afin que vous puissiez l'utiliser directement dans vos pipelines.--output="$VALE_TEMPLATE_PATH" --no-exit à la commande que vous utilisez pour exécuter Vale.vale pour envoyer sa sortie vers un fichier.codequality qui pointe vers l'emplacement du fichier de rapport.Vous pouvez également utiliser ou adapter une définition de job open source pour exécuter l'analyse et intégrer sa sortie à la qualité du code, par exemple :
gitlab-ci-utils de la communauté.Si vous avez déjà un job markdownlint-cli2 dans vos pipelines CI/CD, vous devriez ajouter un rapport pour envoyer sa sortie vers la qualité du code. Pour intégrer sa sortie :
Ajoutez markdownlint-cli2-formatter-codequality comme dépendance de développement dans votre projet.
Si vous n'en avez pas encore, créez un fichier .markdownlint-cli2.jsonc à la racine de votre dépôt.
Ajoutez une directive outputFormatters dans .markdownlint-cli2.jsonc :
{
"outputFormatters": [
[ "markdownlint-cli2-formatter-codequality" ]
]
}
Déclarez un artefact de rapport codequality qui pointe vers l'emplacement du fichier de rapport. Par défaut, le fichier de rapport est nommé markdownlint-cli2-codequality.json.
.gitignore du dépôt.Pour plus de détails et un exemple de définition de job CI/CD, consultez la documentation de markdownlint-cli2-formatter-codequality.