ContextQMD
Back to Gitlabhq

Types de rapports d'artefacts CI/CD

doc-locale/fr-fr/ci/yaml/artifacts_reports.md

19.3.018.8 KB
Original Source

{{< details >}}

  • Édition : Gratuite, GitLab Premium, GitLab Ultimate
  • Offre : GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

Utilisez artifacts:reports pour :

  • Collecter des rapports de tests, des rapports de qualité du code, des rapports de sécurité et d'autres artefacts générés par les modèles inclus dans les jobs.
  • Certains de ces rapports sont utilisés pour afficher des informations dans :

Les artefacts créés pour artifacts: reports sont toujours chargés, quel que soit le résultat du job (succès ou échec). Vous pouvez utiliser artifacts:expire_in pour définir une durée d'expiration pour les artefacts, ce qui remplace le paramètre par défaut de l'instance. GitLab.com peut avoir une valeur d'expiration des artefacts par défaut différente.

Certains types artifacts:reports peuvent être générés par plusieurs jobs dans le même pipeline et utilisés par les fonctionnalités de merge request ou de pipeline de chaque job.

Pour parcourir les fichiers de sortie du rapport, assurez-vous d'inclure le mot-clé artifacts:paths dans la définition de votre job.

[!note] Les rapports combinés dans les pipelines parents utilisant les artefacts des pipelines enfants ne sont pas pris en charge. La prise en charge de cette fonctionnalité est proposée dans l'epic 8205.

artifacts:reports:accessibility {#artifactsreportsaccessibility}

Le rapport accessibility utilise pa11y pour rendre compte de l'impact sur l'accessibilité des modifications introduites dans les merge requests.

GitLab peut afficher les résultats d'un ou plusieurs rapports dans le widget d'accessibilité de la merge request.

Pour plus d'informations, consultez Tests d'accessibilité.

artifacts:reports:annotations {#artifactsreportsannotations}

{{< history >}}

{{< /history >}}

Le rapport annotations est utilisé pour associer des données auxiliaires à un job.

Un rapport d'annotations est un fichier JSON comportant des sections d'annotations. Chaque section d'annotation peut avoir n'importe quel nom souhaité et peut contenir un nombre quelconque d'annotations du même type ou de types différents.

Chaque annotation est une clé unique (le type d'annotation), contenant les sous-clés avec les données de cette annotation.

Types d'annotations {#annotation-types}

external_link {#external_link}

Une annotation external_link peut être associée à un job pour ajouter un lien à la page de sortie du job. La valeur d'une annotation external_link est un objet avec les clés suivantes :

CléDescription
labelLe label lisible par les humains associé au lien.
urlL'URL pointée par le lien.

Exemple de rapport {#example-report}

Voici un exemple de ce à quoi peut ressembler un rapport d'annotations de job :

json
{
  "my_annotation_section_1": [
    {
      "external_link": {
        "label": "URL 1",
        "url": "https://url1.example.com/"
      }
    },
    {
      "external_link": {
        "label": "URL 2",
        "url": "https://url2.example.com/"
      }
    }
  ]
}

artifacts:reports:api_fuzzing {#artifactsreportsapi_fuzzing}

{{< details >}}

  • Édition : Ultimate

{{< /details >}}

Le rapport api_fuzzing collecte les bugs de fuzzing d'API en tant qu'artefacts.

GitLab peut afficher les résultats d'un ou plusieurs rapports dans :

artifacts:reports:browser_performance {#artifactsreportsbrowser_performance}

{{< details >}}

  • Édition : Premium, Ultimate

{{< /details >}}

Le rapport browser_performance collecte les métriques de test de performance du navigateur en tant qu'artefact. Cet artefact est un fichier JSON généré par le plugin GitLab pour sitespeed.io.

GitLab affiche les résultats dans la merge request. Pour plus d'informations, consultez les tests de performance du navigateur.

GitLab ne peut pas afficher les résultats combinés de plusieurs rapports browser_performance.

artifacts:reports:coverage_report {#artifactsreportscoverage_report}

Utilisez coverage_report pour collecter un rapport de couverture au format Cobertura ou JaCoCo. Une fois le pipeline terminé, GitLab analyse le rapport et affiche les annotations de couverture ligne par ligne dans le diff de la merge request.

[!note] Ce mot-clé produit uniquement des annotations de diff. Il n'affiche pas de pourcentage de couverture dans le widget de la MR et ne renseigne pas les graphiques d'historique de couverture. Pour afficher un pourcentage de couverture, configurez séparément le mot-clé coverage.

Pour plus d'informations, consultez la page suivante :

yaml
artifacts:
  reports:
    coverage_report:
      coverage_format: cobertura
      path: coverage/cobertura-coverage.xml

Vous pouvez générer plusieurs rapports et les collecter à l'aide de caractères génériques. GitLab fusionne les résultats en un seul rapport.

Les rapports de couverture des pipelines enfants apparaissent dans les annotations de diff de la merge request, mais ne sont pas partagés avec les pipelines parents.

artifacts:reports:codequality {#artifactsreportscodequality}

Le rapport codequality collecte les problèmes de qualité du code. Le rapport de qualité du code collecté est chargé dans GitLab en tant qu'artefact.

GitLab peut afficher les résultats d'un ou plusieurs rapports dans :

La valeur artifacts:expire_in est définie sur 1 week.

artifacts:reports:container_scanning {#artifactsreportscontainer_scanning}

{{< details >}}

  • Édition : Ultimate

{{< /details >}}

Le rapport container_scanning collecte les vulnérabilités de l'analyse des conteneurs. Le rapport d'analyse des conteneurs collecté est chargé dans GitLab en tant qu'artefact.

GitLab peut afficher les résultats d'un ou plusieurs rapports dans :

artifacts:reports:coverage_fuzzing {#artifactsreportscoverage_fuzzing}

{{< details >}}

  • Édition : Ultimate

{{< /details >}}

Le rapport coverage_fuzzing collecte les bugs de fuzzing de couverture. Le rapport de fuzzing de couverture collecté est chargé dans GitLab en tant qu'artefact. GitLab peut afficher les résultats d'un ou plusieurs rapports dans :

artifacts:reports:cyclonedx {#artifactsreportscyclonedx}

{{< details >}}

  • Édition : Ultimate

{{< /details >}}

Ce rapport est une nomenclature logicielle (Software Bill of Materials) décrivant les composants d'un projet selon le format de protocole CycloneDX.

Vous pouvez spécifier plusieurs rapports CycloneDX par job. Ceux-ci peuvent être fournis sous forme de liste de noms de fichiers, d'un modèle de nom de fichier, ou des deux :

  • Un modèle de nom de fichier (cyclonedx: gl-sbom-*.json, junit: test-results/**/*.json).
  • Un tableau de noms de fichiers (cyclonedx: [gl-sbom-npm-npm.cdx.json, gl-sbom-bundler-gem.cdx.json]).
  • Une combinaison des deux (cyclonedx: [gl-sbom-*.json, my-cyclonedx.json]).
  • Les répertoires ne sont pas pris en charge (cyclonedx: test-results, cyclonedx: test-results/**).

L'exemple suivant montre un job qui expose des artefacts CycloneDX :

yaml
artifacts:
  reports:
    cyclonedx:
      - gl-sbom-npm-npm.cdx.json
      - gl-sbom-bundler-gem.cdx.json

artifacts:reports:dast {#artifactsreportsdast}

{{< details >}}

  • Édition : Ultimate

{{< /details >}}

Le rapport dast collecte les vulnérabilités DAST. Le rapport DAST collecté est chargé dans GitLab en tant qu'artefact.

GitLab peut afficher les résultats d'un ou plusieurs rapports dans :

artifacts:reports:dependency_scanning {#artifactsreportsdependency_scanning}

{{< details >}}

  • Édition : Ultimate

{{< /details >}}

Le rapport dependency_scanning collecte les vulnérabilités d'analyse des dépendances. Le rapport d'analyse des dépendances collecté est chargé dans GitLab en tant qu'artefact.

GitLab peut afficher les résultats d'un ou plusieurs rapports dans :

artifacts:reports:dotenv {#artifactsreportsdotenv}

Le rapport dotenv collecte les variables CI/CD d'un fichier et les rend disponibles en tant que variables CI/CD pour les jobs ultérieurs dans le pipeline.

Pour plus d'informations, consultez les variables dotenv.

artifacts:reports:junit {#artifactsreportsjunit}

Le rapport junit collecte les fichiers XML au format de rapport JUnit. Les rapports de tests unitaires collectés sont chargés dans GitLab en tant qu'artefact. Bien que JUnit ait été développé à l'origine en Java, il existe de nombreux portages tiers pour d'autres langages tels que JavaScript, Python et Ruby.

Consultez Rapports de tests unitaires pour plus de détails et d'exemples. L'exemple suivant montre comment collecter un rapport XML JUnit à partir de tests Ruby RSpec :

yaml
rspec:
  stage: test
  script:
    - bundle install
    - rspec --format RspecJunitFormatter --out rspec.xml
  artifacts:
    reports:
      junit: rspec.xml

GitLab peut afficher les résultats d'un ou plusieurs rapports dans :

Certains outils JUnit exportent vers plusieurs fichiers XML. Vous pouvez spécifier plusieurs chemins de rapport de test dans un seul job pour les concaténer en un seul fichier. Utilisez l'une des options suivantes :

  • Un modèle de nom de fichier (junit: rspec-*.xml, junit: test-results/**/*.xml).
  • Un tableau de noms de fichiers (junit: [rspec-1.xml, rspec-2.xml, rspec-3.xml]).
  • Une combinaison des deux (junit: [rspec.xml, test-results/TEST-*.xml]).
  • Les répertoires ne sont pas pris en charge (junit: test-results, junit: test-results/**).

artifacts:reports:load_performance {#artifactsreportsload_performance}

{{< details >}}

  • Édition : Premium, Ultimate

{{< /details >}}

Le rapport load_performance collecte les métriques de test de performance de charge et est chargé en tant qu'artefact.

Les résultats sont affichés dans le widget de test de charge de la merge request. Les résultats combinés de plusieurs rapports load_performance ne sont pas pris en charge.

artifacts:reports:metrics {#artifactsreportsmetrics}

{{< details >}}

  • Édition : Premium, Ultimate

{{< /details >}}

Le rapport metrics collecte les métriques. Le rapport de métriques collecté est chargé dans GitLab en tant qu'artefact.

GitLab peut afficher les résultats d'un ou plusieurs rapports dans le widget de rapports de métriques de la merge request.

artifacts:reports:requirements {#artifactsreportsrequirements}

{{< details >}}

  • Édition : Ultimate

{{< /details >}}

Le rapport requirements collecte les fichiers requirements.json. Le rapport d'exigences collecté est chargé dans GitLab en tant qu'artefact et les exigences existantes sont marquées comme satisfaites.

GitLab peut afficher les résultats d'un ou plusieurs rapports dans les exigences du projet.

artifacts:reports:sarif {#artifactsreportssarif}

{{< details >}}

  • Édition : Ultimate

{{< /details >}}

{{< history >}}

{{< /history >}}

[!flag] La disponibilité de cette fonctionnalité est contrôlée par un feature flag nommé sarif_ingestion. Pour plus d'informations, consultez l'historique.

Le rapport sarif collecte les résultats de sécurité provenant d'outils émettant une sortie SARIF 2.1.0. Le rapport SARIF collecté est chargé dans GitLab en tant qu'artefact.

Utilisez ce type de rapport pour ingérer les résultats de n'importe quel scanner compatible SARIF, tel que Semgrep, les plugins de sécurité ESLint ou les outils GitHub Advanced Security.

GitLab peut afficher les résultats d'un ou plusieurs rapports dans :

Exemple :

yaml
semgrep:
  image: returntocorp/semgrep
  script:
    - semgrep ci --sarif --output gl-sarif-report.sarif
  artifacts:
    reports:
      sarif: gl-sarif-report.sarif

Pour plus d'informations sur le comportement, les limites, le mappage des champs et les types de rapports inférés, consultez Rapports SARIF.

artifacts:reports:sast {#artifactsreportssast}

Le rapport sast collecte les vulnérabilités SAST. Le rapport SAST collecté est chargé dans GitLab en tant qu'artefact.

Pour plus d'informations, consultez la page suivante :

artifacts:reports:secret_detection {#artifactsreportssecret_detection}

Le rapport secret-detection collecte les secrets détectés. Le rapport de détection des secrets collecté est chargé dans GitLab.

GitLab peut afficher les résultats d'un ou plusieurs rapports dans :

artifacts:reports:terraform {#artifactsreportsterraform}

Le rapport terraform obtient un fichier OpenTofu tfplan.json. Traitement JQ requis pour supprimer les informations d'identification. Le rapport de plan OpenTofu collecté est chargé dans GitLab en tant qu'artefact.

GitLab peut afficher les résultats d'un ou plusieurs rapports dans le widget OpenTofu de la merge request.

Pour plus d'informations, consultez Afficher les informations tofu plan dans une merge request.