Descargar CodeChecker Action - Descargar el código fuente CodeChecker Action

CodeChecker Action

Otras categorias

v1.0.4

Descargar

Acción de análisis estático CodeChecker C ++

Acción de GitHub para ejecutar el análisis estático sobre el uso de CodeChecker como su controlador. Para proyectos de la familia C (C, C ++, Objective-C, CUDA, etc.), CodeChecker admite impulsar los programas de análisis estático de Clang. La salida de varios otros analizadores estáticos se puede integrar en CodeChecker a través del convertidor de informes.

Descripción general (para proyectos de la familia C)

️ ¡PRECAUCIÓN! ¡Esta acción ha sido escrita con comandos que se dirigen a distribuciones basadas en Ubuntu!

Este script compuesto de acción única abarca los siguientes pasos:

Obtenga un paquete de los analizadores de la suite LLVM Clang y CodeChecker.
(Opcional) Registre los comandos de compilación para prepararse para el análisis.
Ejecutar el análisis.
Muestre los resultados del análisis en el registro de CI y cree informes HTML que se pueden cargar como un artefacto. (¡La carga debe ser realizada por el usuario!)
(Opcional) Verifique la confirmación actual de la introducción de nuevos informes de errores contra un estado conocido. (¡Bien por solicitudes de extracción!)
(Opcional) Cargue los resultados en un servidor de CodeChecker en ejecución. (¡Bueno para el proyecto principal!)

NOTA: El análisis estático puede ser un proceso que consume mucho tiempo. Se recomienda que el paso de análisis estático no sea secuencial con el resto de una ejecución de CI, pero se ejecuta como su propio trabajo en un flujo de trabajo, o un flujo de trabajo completamente distinto.

Asegúrese de que su proyecto esté completamente configurado para una compilación antes de ejecutar esta acción.

Nota: Los analizadores estáticos pueden confiar en información adicional que se optimiza en una verdadera compilación de lanzamiento. Por lo tanto, se recomienda configurar su proyecto en una configuración Debug .

Especificando el proyecto para analizar

Agregue el trabajo a su CI de la siguiente manera. Las dos versiones son mutuamente excluyentes: puede dar una base de datos de compilación o instruir a CodeChecker para que cree una.

Proyectos que pueden generar una base de datos de compilación JSON y construir limpiamente (sin código generado)

Algunos proyectos son lo suficientemente triviales en su configuración de compilación que no se deben tomar pasos adicionales después de ejecutar configure.sh , cmake o herramientas similares. Si puede generar una base de datos de compilación desde su sistema de compilación sin ejecutar la compilación en sí, puede ahorrar algo de tiempo e ir al análisis de inmediato.

Puede especificar la base de datos de compilación generada en 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 }}

Proyectos que necesitan crear una base de datos de compilación JSON o requieren código generado

Otros tipos de proyectos pueden depender en gran medida del código generado . Al observar el código fuente de estos proyectos sin que se haya ejecutado una compilación de antemano, no se compilan; como tal, el análisis tampoco se puede ejecutar.

En este caso, deberá instruir a CodeChecker para registrar una compilación (y pasar tiempo haciendo la compilación) justo antes del análisis.

Puede especificar la compilación para ejecutar en 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 }}

Rompiendo la construcción si hay advertencias de análisis estáticos

Si se solicita, la variable de salida warnings se puede igualar para ejecutar un paso en el trabajo que rompe todo el trabajo si el proyecto emitió advertencias de análisis estático.

Nota: Debido a que el análisis estático es potencialmente ruidoso y los informes son difíciles de arreglar, el comportamiento y la recomendación predeterminados es solo informar los hallazgos, pero no rompa todo el IC.

Para obtener los informes en forma de consumo humano, deben cargarse en algún lugar primero, ¡antes de que el paso de falla falle en todo el trabajo!

 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

Cargar resultados a un servidor CodeChecker

Si su proyecto aloja un servidor CodeChecker en algún lugar, el trabajo se puede configurar para crear o actualizar automáticamente una ejecución.

 # 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"

Actuar como una puerta CI en solicitudes de extracción

CodeChecker es capaz de calcular la diferencia entre dos análisis. Si se almacena un análisis de la versión estable del proyecto (ver arriba) en un servidor, se puede configurar un trabajo para solicitudes de extracción que rechaza automáticamente una solicitud de extracción si intenta introducir nuevos hallazgos de análisis.

Para obtener los informes en forma de consumo humano, deben cargarse en algún lugar primero, ¡antes de que el paso de falla falle en todo el trabajo!

 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

Descripción general (para otros análisis a través del convertidor de informes )

️ ¡PRECAUCIÓN! ¡Esta acción ha sido escrita con comandos que se dirigen a distribuciones basadas en Ubuntu!

Este script compuesto de acción única abarca los siguientes pasos:

Obtenga un paquete de CodeChecker.
Use el report-converter para convertir los informes de otros analizadores en formato de CodeChecker.
Muestre los resultados del análisis en el registro de CI y cree informes HTML que se pueden cargar como un artefacto. (¡La carga debe ser realizada por el usuario!)
(Opcional) Verifique la confirmación actual de la introducción de nuevos informes de errores contra un estado conocido. (¡Bien por solicitudes de extracción!)
(Opcional) Cargue los resultados en un servidor de CodeChecker en ejecución. (¡Bueno para el proyecto principal!)

NOTA: El análisis estático puede ser un proceso que consume mucho tiempo. Se recomienda que el paso de análisis estático no sea secuencial con el resto de una ejecución de CI, pero se ejecuta como su propio trabajo en un flujo de trabajo, o un flujo de trabajo completamente distinto.

Consulte la documentación del analizador de su elección para esto. CodeChecker no admite impulsar el análisis a través de herramientas externas, pero si se había realizado un análisis exitoso, puede convertir y almacenar los resultados.

 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 }}

Cargar resultados y actuar como una puerta CI

La herramienta de informe de informes convierte la salida de varios analizadores en el formato común utilizado por CodeChecker. Una vez que se realiza la conversión, el resto de las características de la acción pueden ejecutarse de la misma manera que para los proyectos C/C ++. Consulte las partes anteriores de la documentación para la configuración de estas características.

Configuración de acción

Variable	Por defecto	Descripción
`config`	`$(project-root)/.codechecker.json`	El archivo de configuración que contiene los indicadores para agregar a los comandos de análisis. Se recomienda que la mayor parte de la configuración del análisis esté versión con el proyecto. ? Lea más sobre el archivo de configuración `codechecker.json` en la documentación oficial.

Versiones para instalar

Variable	Por defecto	Descripción
`llvm-version`	`latest`	La versión principal de LLVM para instalar y usar. LLVM se instala desde la comunidad PPA. ¡El valor debe ser una versión importante (por ejemplo, `13` ) que es compatible con el PPA para el sistema operativo utilizado! Si es `latest` , reúna automáticamente la última versión (aún inédita). Si `ignore` , no instale nada. (No recomendado).
`install-custom`	`false`	Si se establece en `true` , abre la capacidad de clonar localmente e instalar CodeChecker desde el `repository` y `version` especificados. De lo contrario, `version` se toma como una versión de lanzamiento, y se descarga el suite CodeChecker de Pypi.
`repository`	`Ericsson/CodeChecker`	El repositorio de CodeChecker para verificar y construir, si `install-custom` es `true` .
`version`	`master`	Si `install-custom` es `false` , la versión de lanzamiento (por ejemplo, `6.18.0` ) se descargará desde PYPI, o `master` para obtener la última versión. De lo contrario, la rama (predeterminada al `master` ), la etiqueta o la comedia SHA en el `repository` para verificar.

Configuración de registro de compilación

? Lea más sobre CodeChecker log en la documentación oficial.

Variable	Por defecto	Descripción
`logfile`		La ubicación de la base de datos de compilación JSON que describe cómo se construye el proyecto. Este indicador se utiliza si el sistema de compilación puede pregenerarse el archivo para nosotros.
`build-command`		El comando de compilación para ejecutar. CodeChecker es capaz de ejecutar y registrar la compilación para sí misma. Este indicador se utiliza si el sistema de compilación no puede generar la información por sí solo, o el proyecto se basa en otro código generado.

Configuración de análisis

? Lea más sobre CodeChecker analyze en la documentación oficial.

Variable	Por defecto	Descripción
`analyze-output`	(Generado automático)	El directorio donde se debe almacenar la salida de análisis sin procesar .
`ctu`	`false`	Habilite el análisis de la unidad de traducción cruzada en el analizador estático de Clang . ️ ¡PRECAUCIÓN! El análisis de CTU puede llevar mucho tiempo, y CTU se considera oficialmente como experimental.
`ignore-analyze-crashes`	`true`	Si se establece en `true` , la fase de análisis no informará un error si algunas acciones de análisis fallan (debido a posibles bloqueos en CLANG).

Configuración de informes

? Lea más sobre CodeChecker parse en la documentación oficial.

Informe de configuración de conversión

? Lea más sobre el report-converter en la documentación oficial.

Variable	Por defecto	Descripción
`report-converter`	`false`	Si se establece en `true` , el trabajo ejecutará la conversión de informes de otros analizadores en lugar de impulsar el análisis estático por sí mismo.
`original-analyser`		El "tipo" del análisis que se había realizado anteriormente. Aprobado como aportes obligatorios al ejecutable `report-converter` .
`original-analysis-output`		El archivo o directorio donde están disponibles los resultados del analizador de terceros. Aprobado como aportes obligatorios al ejecutable `report-converter` .

Configuración diff

? Lea más sobre CodeChecker cmd diff en la documentación oficial.

? La comprobación de los resultados del análisis en el contenido de un servidor requiere el permiso PRODUCT_VIEW , si el servidor requiere autenticación.

Variable	Por defecto	Descripción
`diff`	`false`	Si se establece en `true` , el trabajo calculará una diferencia de los resultados del análisis actual con los resultados almacenados en un servidor remoto.
`diff-url`		La URL del producto CodeChecker para verificar y difundir, incluido el punto final. Por lo general, en el formato de `http://example.com/ProductName` . Se requiere especificar esta variable si se estableció `diff` en `true` .
`diff-username`		Si el servidor requiere autenticación para acceder, especifique el nombre de usuario con el que debe iniciar sesión el cheque.
`diff-password`		La contraseña o el token de acceso generado correspondiente al usuario. ? NOTA: Se recomienda que esto se configure como un secreto de repositorio, y dado como tal: `${{ secrets.CODECHECKER_PASSWORD }}` al configurar la acción.
`diff-run-name`	(Generado automático, en el formato `user/repo: branchname` )	Las ejecuciones de análisis de CodeChecker se recopilan en ejecuciones . Una ejecución generalmente se correlaciona con una configuración del análisis.

Configuración de almacenamiento

? Lea más sobre CodeChecker store en la documentación oficial.

? El almacenamiento se ejecuta en un servidor requiere el permiso PRODUCT_STORE , si el servidor requiere autenticación.

Variable	Por defecto	Descripción
`store`	`false`	Si se establece en `true` , el script cargará los resultados en un servidor CodeChecker. ¡Por lo general, otras banderas también deben configurarse!
`store-url`		La URL del producto CodeChecker para almacenar, incluido el punto final. Por lo general, en el formato de `http://example.com/ProductName` . Se requiere especificar esta variable si `store` se estableció en `true` .
`store-username`		Si el servidor requiere autenticación para acceder, especifique el nombre de usuario con el que debe iniciar sesión la carga.
`store-password`		La contraseña o el token de acceso generado correspondiente al usuario. ? NOTA: Se recomienda que esto se configure como un secreto de repositorio, y dado como tal: `${{ secrets.CODECHECKER_PASSWORD }}` al configurar la acción.
`store-run-name`	(Generado automático, en el formato `user/repo: branchname` )	Las ejecuciones de análisis de CodeChecker se recopilan en ejecuciones . Una ejecución generalmente se correlaciona con una configuración del análisis. Las ejecuciones se pueden almacenar de forma incremental, en cuyo caso CodeChecker puede anotar que los informes se solucionaron.

`outputs` de acción para usar en más de pasos

La acción expone las siguientes salidas que pueden usarse en los pasos de un flujo de trabajo que tiene éxito en el análisis.

Variable	Valor	Descripción
`analyze-output`	Entrada generada por auto o `analyze-output`	El directorio donde los archivos de salida de análisis sin procesar (creados por los analizadores o por el convertidor) están disponibles.
`codechecker-version`	Generado automático (probablemente igual que `version` de entrada)	La versión del CodeChecker instalado que realizó el análisis.
`codechecker-hash`	Generado automático.	El hash Git del CodeChecker instalado que realizó el análisis.
`logfile`	Entrada generada automáticamente o `logfile`	La base de datos de compilación JSON del análisis que se ejecutó.
`llvm-version`	Generado automático.	La cadena de versión completa del paquete LLVM/Clang instalado (según lo informado por `clang --version` ).
`diff-html-dir`	Generado automático.	El directorio donde se generaron los informes de errores HTML fáciles de usar sobre los nuevos hallazgos (si se habilitaba `diff` ).
`diff-result-log`	Generado automático.	El archivo de registro de salida `CodeChecker cmd diff` que contiene los nuevos hallazgos descargados en él.
`diff-run-name`	Entrada generada por auto o `diff-run-name`	El nombre de la ejecución del análisis (si se habilitó `diff` ) con el cual se compararon los informes.
`result-html-dir`	Generado automático.	El directorio donde se generaron los informes de errores HTML fáciles de usar .
`result-log`	Generado automático.	El archivo de registro de salida `CodeChecker parse` que contiene los hallazgos descargados en él.
`store-run-name`	Entrada generada automáticamente o `store-run-name`	El nombre de la ejecución del análisis (si `store` estaba habilitado) al que se cargaron los resultados.
`store-successful`	`true` o `false`	Si el almacenamiento de los resultados tuvo éxito. Útil para romper opcionalmente la compilación más tarde para detectar fallas de red.
`warnings`	`true` o `false`	Si los analizadores estáticos informaron algún hallazgo.
`warnings-in-diff`	`true` o `false`	Si se habilitó `diff` , si hubo nuevos hallazgos en el análisis actual en comparación con el contenido del servidor.