CodeChecker Action Download - CodeChecker Action Code source Télécharger

CodeChecker Action

Autres catégories

v1.0.4

Télécharger

CodeChecker C ++ Action d'analyse statique

Action GitHub pour exécuter une analyse statique par rapport à l'utilisation de CodeChecker comme pilote. Pour les projets de la famille C (C, C ++, Objective-C, CUDA, etc.), CodeChecker soutient la conduite des programmes d'analyse statique de Clang. Plusieurs autres résultats des analyseurs statiques peuvent être intégrés dans CodeChecker via le convertisseur de rapport.

Aperçu (pour les projets de famille C)

️ PRUDENCE! Cette action a été écrite avec des commandes qui ciblent les distributions basées sur Ubuntu!

Ce script composite à action unique englobe les étapes suivantes:

Obtenez un paquet des analyseurs de la suite Clang LLVM et du CodeChecker.
(Facultatif) Journire les commandes de build pour se préparer à l'analyse.
Exécuter l'analyse.
Montrez les résultats de l'analyse dans le journal CI et créez des rapports HTML qui peuvent être téléchargés comme un artefact. (Le téléchargement est à faire par l'utilisateur!)
(Facultatif) Vérifiez le commit actuel introduisant de nouveaux rapports de bogues contre un état connu. (Bon pour les demandes de traction!)
(Facultatif) Téléchargez les résultats sur un serveur CodeChecker en cours. (Bon pour le projet principal!)

Remarque: L'analyse statique peut être un processus long. Il est recommandé que l'étape d'analyse statique ne soit pas séquentielle avec le reste d'une exécution CI, mais fonctionne comme son propre travail dans un flux de travail, soit un flux de travail complètement distinct.

Veuillez vous assurer que votre projet est complètement configuré pour une version avant d'exécuter cette action.

Remarque: Les analyseurs statiques peuvent s'appuyer sur des informations supplémentaires optimisées dans une véritable version de version. Par conséquent, il est recommandé de configurer votre projet dans une configuration Debug .

Spécifiant le projet à analyser

Ajoutez le travail dans votre CI comme suit. Les deux versions s'excluent mutuellement - vous pouvez soit donner une base de données de compilation, ou vous demandez à CodeChecker d'en créer un.

Projets qui peuvent générer une base de données de compilation JSON et construire proprement (pas de code généré)

Certains projets sont assez triviaux dans leur configuration de construction pour qu'aucune étape supplémentaire ne doit être prise après avoir exécuté configure.sh , cmake ou outils similaires. Si vous êtes en mesure de générer une base de données de compilation à partir de votre système de construction sans exécuter la construction elle-même, vous pouvez gagner du temps et vous rendre immédiatement à l'analyse.

Vous pouvez spécifier la base de données de compilation générée dans la variable logfile

 job :
  steps :
    # Check YOUR project out!
    - name : " Check out repository "
      uses : actions/checkout@v2

    # Prepare a build
    - name : " Prepare build "
      run : |
        mkdir -pv Build
        cd Build
        cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

    # Run the analysis
    - uses : whisperity/codechecker-analysis-action@v1
      id : codechecker
      with :
        logfile : ${{ github.workspace }}/Build/compile_commands.json

    # Upload the results to the CI.
    - uses : actions/upload-artifact@v2
      with :
        name : " CodeChecker Bug Reports "
        path : ${{ steps.codechecker.outputs.result-html-dir }}

Les projets qui ont besoin d'auto-créer une base de données de compilation JSON ou de nécessiter un code généré

D'autres types de projets peuvent s'appuyer fortement sur le code généré . Lorsque l'on considère le code source de ces projets sans que la construction n'ait été exécutée au préalable, ils ne compilent pas - en tant que telle, l'analyse ne peut pas non plus être exécutée.

Dans ce cas, vous devrez demander à CodeChecker de enregistrer une construction (et de passer du temps à faire la construction) juste avant l'analyse.

Vous pouvez spécifier la version à exécuter dans la variable build-command .

 job :
  steps :
    # Check YOUR project out!
    - name : " Check out repository "
      uses : actions/checkout@v2

    # Prepare a build
    - name : " Prepare build "
      run : |
        mkdir -pv Build
        cd Build
        cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=OFF

    # Run the analysis
    - uses : whisperity/codechecker-analysis-action@v1
      id : codechecker
      with :
        build-command : " cd ${{ github.workspace }}/Build; cmake --build . "

    # Upload the results to the CI.
    - uses : actions/upload-artifact@v2
      with :
        name : " CodeChecker Bug Reports "
        path : ${{ steps.codechecker.outputs.result-html-dir }}

Briser la construction s'il y a des avertissements d'analyse statique

On leur demande, la variable de sortie warnings peut être jumelée pour exécuter une étape dans le travail qui rompt l'intégralité du travail si des avertissements d'analyse statique ont été émis par le projet.

Remarque: En raison de l'analyse statique, potentiellement bruyante et que les rapports sont difficiles à corriger, le comportement et la recommandation par défaut sont de signaler uniquement les résultats mais ne brisent pas l'intégralité de l'IC.

Pour obtenir les rapports sous une forme consommable de l'homme, ils doivent être téléchargés quelque part en premier, avant que l'étape d'échec échoue tout le travail!

 job :
  steps :
    # Check YOUR project out!
    - name : " Check out repository "
      uses : actions/checkout@v2

    # Prepare a build
    - name : " Prepare build "
      run : |
        mkdir -pv Build
        cd Build
        cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=OFF

    # Run the analysis
    - uses : whisperity/codechecker-analysis-action@v1
      id : codechecker
      with :
        build-command : " cd ${{ github.workspace }}/Build; cmake --build . "

    # Upload the results to the CI.
    - uses : actions/upload-artifact@v2
      with :
        name : " CodeChecker Bug Reports "
        path : ${{ steps.codechecker.outputs.result-html-dir }}

    # Break the build if there are *ANY* warnings emitted by the analysers.
    - name : " Break build if CodeChecker reported any findings "
      if : ${{ steps.codechecker.outputs.warnings == 'true' }}
      run : exit 1

Téléchargement des résultats sur un serveur CodeChecker

Si votre projet héberge un serveur CodeChecker quelque part, le travail peut être configuré pour créer ou mettre à jour automatiquement une exécution.

 # It is recommended that storing only happens for PUSH events, and preferably
# only for long-term branches.
on :
  push :

job :
  steps :
    # Check YOUR project out!
    - name : " Check out repository "
      uses : actions/checkout@v2

    # Prepare a build
    - name : " Prepare build "
      run : |
        mkdir -pv Build
        cd Build
        cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=OFF

    # Run the analysis
    - uses : whisperity/codechecker-analysis-action@v1
      id : codechecker
      with :
        build-command : " cd ${{ github.workspace }}/Build; cmake --build . "
        store : true
        store-url : ' http://example.com:8001/MyProject '
        store-username : ${{ secrets.CODECHECKER_STORE_USER }}
        store-password : ${{ secrets.CODECHECKER_STORE_PASSWORD }}
        # store-run-name: "custom run name to store against"

Agir comme une porte CI sur les demandes de traction

CodeChecker est capable de calculer la différence entre deux analyses. Si une analyse de la version stable du projet est stockée (voir ci-dessus) sur un serveur, un travail pour les demandes de traction peut être configuré qui rejette automatiquement une demande de traction si elle essaie d'introduire de nouvelles résultats d'analyse.

Pour obtenir les rapports sous une forme consommable de l'homme, ils doivent être téléchargés quelque part en premier, avant que l'étape d'échec échoue tout le travail!

 on :
  pull_request :

runs :
  steps :
    # Check the pull request out! (In pull_request jobs, the checkout action
    # automatically downloads the "after-merge" state of the pull request if
    # there are no conflicts.)
    - name : " Check out repository "
      uses : actions/checkout@v2

    # Prepare a build
    - name : " Prepare build "
      run : |
        mkdir -pv Build
        cd Build
        cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS=OFF

    # Run the analysis
    - uses : whisperity/codechecker-analysis-action@v1
      id : codechecker
      with :
        build-command : " cd ${{ github.workspace }}/Build; cmake --build . "

        store : ${{ github.event_name == 'push' }}
        store-url : ' http://example.com:8001/MyProject '
        store-username : ${{ secrets.CODECHECKER_STORE_USER }}
        store-password : ${{ secrets.CODECHECKER_STORE_PASSWORD }}
        # Keep the names for 'store' and 'diff' in sync, or auto-generated!
        # diff-run-name: "custom run name to store with"

        diff : ${{ github.event_name == 'pull_request' }}
        diff-url : ' http://example.com:8001/MyProject '
        diff-username : ${{ secrets.CODECHECKER_DIFF_USER }}
        diff-password : ${{ secrets.CODECHECKER_DIFF_PASSWORD }}
        # diff-run-name: "custom run name to diff against"

    # Upload the potential new findings results to the CI.
    - uses : actions/upload-artifact@v2
      if : ${{ steps.codechecker.outputs.warnings-in-diff == 'true' }}
      with :
        name : " New introduced results Bug Reports "
        path : ${{ steps.codechecker.outputs.diff-html-dir }}

    - name : " Fail the job if new findings are introduced "
      if : ${{ steps.codechecker.outputs.warnings-in-diff == 'true' }}
      shell : bash
      run : |
        echo "::error title=New static analysis warnings::Analysed commit would introduce new static analysis warnings and potential bugs to the project"
        # Fail the build, after results were collected and uploaded.
        exit 1

Aperçu (pour d'autres analyses via le rapport-convertisseur )

️ PRUDENCE! Cette action a été écrite avec des commandes qui ciblent les distributions basées sur Ubuntu!

Ce script composite à action unique englobe les étapes suivantes:

Obtenez un paquet de CodeChecker.
Utilisez le report-converter pour convertir les rapports d'autres analyseurs au format de CodeChecker.
Montrez les résultats de l'analyse dans le journal CI et créez des rapports HTML qui peuvent être téléchargés comme un artefact. (Le téléchargement est à faire par l'utilisateur!)
(Facultatif) Vérifiez le commit actuel introduisant de nouveaux rapports de bogues contre un état connu. (Bon pour les demandes de traction!)
(Facultatif) Téléchargez les résultats sur un serveur CodeChecker en cours. (Bon pour le projet principal!)

Remarque: L'analyse statique peut être un processus long. Il est recommandé que l'étape d'analyse statique ne soit pas séquentielle avec le reste d'une exécution CI, mais fonctionne comme son propre travail dans un flux de travail, soit un flux de travail complètement distinct.

Veuillez vous référer à la documentation de l'analyseur de votre choix pour cela. CodeChecker ne prend pas en charge la conduite de l'analyse via des outils externes, mais si une analyse réussie avait été effectuée, elle peut convertir et stocker les résultats.

 job :
  steps :
    # Check YOUR project out!
    - name : " Check out repository "
      uses : actions/checkout@v2

    # Perform the analysis. Details vary between analysers!
    # Example for "PyLint" added below!
    - name : " Analyse with PyLint "
      run : |
        sudo apt-get -y install pylint
        pylint -f json --exit-zero myproject > pylint_reports.json

    # Run the conversion
    - uses : whisperity/codechecker-analysis-action@v1
      id : codechecker
      with :
        report-converter : true
        original-analyser : " pylint "
        original-analysis-output : " pylint_reports.json "

    # Upload the results (after conversion by CodeChecker) to the CI.
    - uses : actions/upload-artifact@v2
      with :
        name : " CodeChecker Bug Reports "
        path : ${{ steps.codechecker.outputs.result-html-dir }}

Télécharger les résultats et agir comme une porte CI

L'outil de convertisseur de rapport convertit la sortie de divers analyseurs au format commun utilisé par CodeChecker. Une fois la conversion terminée, le reste des fonctionnalités de l'action peut s'exécuter de la même manière que pour les projets C / C ++. Veuillez vous référer aux parties antérieures de la documentation pour la configuration de ces fonctionnalités.

Configuration d'action

Variable	Défaut	Description
`config`	`$(project-root)/.codechecker.json`	Le fichier de configuration contenant des drapeaux à ajouter aux commandes d'analyse. Il est recommandé que la majeure partie de la configuration d'analyse soit versée avec le projet. ? En savoir plus sur le fichier de configuration `codechecker.json` dans la documentation officielle.

Versions à installer

Variable	Défaut	Description
`llvm-version`	`latest`	La version principale de LLVM à installer et à utiliser. LLVM est installé à partir de la communauté PPA. La valeur doit être une version majeure (par exemple `13` ) qui est prise en charge par le PPA pour le système d'exploitation utilisé! Si `latest` , rassemblez automatiquement la dernière version (mais inédite). Si `ignore` , n'installez rien. (Non recommandé.)
`install-custom`	`false`	S'il est défini sur `true` , ouvre la possibilité de cloner localement et d'installer CodeChecker à partir du `repository` et `version` spécifiés. Sinon, `version` est prise comme une version de version, et la suite CodeChecker de PYPI est téléchargée.
`repository`	`Ericsson/CodeChecker`	Le référentiel CodeChecker à vérifier et à construire, si `install-custom` est `true` .
`version`	`master`	Si `install-custom` est `false` , la version de version (par exemple `6.18.0` ) à télécharger à partir de PYPI, ou `master` pour récupérer la dernière version. Sinon, la branche (défautant pour `master` ), la balise ou commet SHA dans le `repository` pour vérifier.

Configuration du journal de création

? En savoir plus sur CodeChecker log dans la documentation officielle.

Variable	Défaut	Description
`logfile`		L'emplacement de la base de données de compilation JSON qui décrit comment le projet est construit. Ce drapeau est utilisé si le système de construction peut pré-générer le fichier pour nous.
`build-command`		La commande build à exécuter. CodeChecker est capable d'exécuter et de journaliser la construction pour lui-même. Ce drapeau est utilisé si le système de construction ne peut pas générer les informations par lui-même, ou si le projet repose sur un autre code généré.

Configuration d'analyse

? En savoir plus sur CodeChecker analyze dans la documentation officielle.

Variable	Défaut	Description
`analyze-output`	(généré automatiquement)	Le répertoire où la sortie de l'analyse brute doit être stockée.
`ctu`	`false`	Activer l'analyse de l'unité de traduction croisée dans l' analyseur statique Clang . ️ PRUDENCE! L'analyse CTU pourrait prendre très longtemps et CTU est officiellement considérée comme expérimentale.
`ignore-analyze-crashes`	`true`	Si elle est définie sur `true` , la phase d'analyse ne rapportera pas une erreur si certaines actions d'analyse échouent (en raison de plantages potentiels dans Clang).

Configuration de rapport

? En savoir plus sur CodeChecker parse dans la documentation officielle.

Configuration de la conversion de rapport

? En savoir plus sur le report-converter dans la documentation officielle.

Variable	Défaut	Description
`report-converter`	`false`	Si elle est définie sur `true` , le travail exécutera la conversion de rapport à partir d'autres analyseurs au lieu de conduire en soi l'analyse statique.
`original-analyser`		Le "type" de l'analyse qui avait été effectué plus tôt. Passé comme entrée obligatoire à l'exécutable `report-converter` .
`original-analysis-output`		Le fichier ou le répertoire où les résultats de l'analyseur tiers sont disponibles. Passé comme entrée obligatoire à l'exécutable `report-converter` .

Configuration de difficulté

? En savoir plus sur CodeChecker cmd diff dans la documentation officielle.

? La vérification des résultats de l'analyse par rapport au contenu d'un serveur nécessite l'autorisation PRODUCT_VIEW , si le serveur nécessite une authentification.

Variable	Défaut	Description
`diff`	`false`	S'il est défini sur `true` , le travail calculera un différentiel des résultats de l'analyse actuels par rapport aux résultats stockés sur un serveur distant.
`diff-url`		L'URL du produit CodeChecker pour vérifier et diffuser, y compris le point final. Habituellement dans le format de `http://example.com/ProductName` . La spécification de cette variable est requise si `diff` a été défini sur `true` .
`diff-username`		Si le serveur nécessite une authentification pour accéder, spécifiez le nom d'utilisateur avec lequel le chèque doit se connecter.
`diff-password`		Le mot de passe ou le jeton d'accès généré correspondant à l'utilisateur. ? Remarque: il est recommandé que cela soit configuré comme un secret de référentiel, et donné comme tel: `${{ secrets.CODECHECKER_PASSWORD }}` lors de la configuration de l'action.
`diff-run-name`	(généré automatiquement, au format `user/repo: branchname` )	Les exécutions d'analyse CodeChecker sont collectées en exécution . Une exécution est généralement en corrélation avec une configuration de l'analyse.

Configuration de stockage

? En savoir plus sur CodeChecker store dans la documentation officielle.

? Le stockage des exécutions vers un serveur nécessite l'autorisation PRODUCT_STORE , si le serveur nécessite une authentification.

Variable	Défaut	Description
`store`	`false`	S'il est défini sur `true` , le script téléchargera les résultats sur un serveur CodeChecker. Habituellement, d'autres drapeaux doivent également être configurés!
`store-url`		L'URL du produit CodeChecker à stocker, y compris le point final. Habituellement dans le format de `http://example.com/ProductName` . La spécification de cette variable est requise si `store` était défini sur `true` .
`store-username`		Si le serveur nécessite une authentification pour accéder, spécifiez le nom d'utilisateur avec lequel le téléchargement doit se connecter.
`store-password`		Le mot de passe ou le jeton d'accès généré correspondant à l'utilisateur. ? Remarque: il est recommandé que cela soit configuré comme un secret de référentiel, et donné comme tel: `${{ secrets.CODECHECKER_PASSWORD }}` lors de la configuration de l'action.
`store-run-name`	(Généré automatiquement, au format `user/repo: branchname` )	Les exécutions d'analyse CodeChecker sont collectées en exécution . Une exécution est généralement en corrélation avec une configuration de l'analyse. Les exécutions peuvent être stockées progressivement, auquel cas CodeChecker est en mesure d'annoter que les rapports ont été réparés.

`outputs` d'action à utiliser dans d'autres étapes

L'action expose les sorties suivantes qui peuvent être utilisées dans les étapes d'un workflow succédant à l'analyse.

Variable	Valeur	Description
`analyze-output`	Entrée générée automatiquement ou `analyze-output`	Le répertoire où les fichiers de sortie de l'analyse brute (créés par les analyseurs, soit par le convertisseur) sont disponibles.
`codechecker-version`	Généré automatiquement (probablement identique à `version` d'entrée)	La version du CodeChecker installé qui a effectué l'analyse.
`codechecker-hash`	Généré automatiquement.	Le hachage GIT du CodeChecker installé qui a effectué l'analyse.
`logfile`	Entrée générée `logfile` automatiquement ou	La base de données de compilation JSON de l'analyse qui a été exécutée.
`llvm-version`	Généré automatiquement.	La chaîne de version complète du package LLVM / Clang installé (comme indiqué par `clang --version` ).
`diff-html-dir`	Généré automatiquement.	Le répertoire où les rapports de bogues HTML conviviaux ont été générés pour les nouvelles conclusions (si `diff` a été activé).
`diff-result-log`	Généré automatiquement.	Le fichier de journal de sortie `CodeChecker cmd diff` qui contient les nouvelles découvertes qui y sont déversées.
`diff-run-name`	Entrée générée automatiquement ou `diff-run-name`	Le nom de l'analyse exécuté (si `diff` a été activé) par rapport à lequel les rapports ont été comparés.
`result-html-dir`	Généré automatiquement.	Le répertoire où les rapports de bogues HTML conviviaux ont été générés.
`result-log`	Généré automatiquement.	Le fichier de journal de sortie `CodeChecker parse` qui contient les résultats qui y sont déversés.
`store-run-name`	Entrée générée par automatiquement ou `store-run-name`	Le nom de l'analyse exécute (si `store` était activé) auquel les résultats ont été téléchargés.
`store-successful`	`true` ou `false`	Si le stockage des résultats a réussi. Utile pour briser éventuellement la construction plus tard pour détecter les échecs de réseautage.
`warnings`	`true` ou `false`	Si les analyseurs statiques ont signalé des résultats.
`warnings-in-diff`	`true` ou `false`	Si `diff` a été activé, s'il y avait de nouvelles résultats dans l'analyse actuelle par rapport au contenu du serveur.