Análisis de solicitudes de fusión en GitLab usando PVS-Studio para C#

¿Te encanta GitLab y odias los errores? ¿Quiere mejorar la calidad de su código fuente? Entonces has venido al lugar correcto. Hoy le diremos cómo configurar el analizador PVS-Studio C# para verificar las solicitudes de fusión. Tengan un humor de unicornio y feliz lectura para todos.

PVS-Estudio es una herramienta para identificar errores y posibles vulnerabilidades en el código fuente de programas escritos en C, C++, C# y Java. Funciona en sistemas de 64 bits en Windows, Linux y macOS. Puede analizar código diseñado para plataformas ARM integradas y de 32 bits, 64 bits.

Por cierto, lanzamos PVS-Studio 7.08, en el que hicimos muchas cosas interesante. Por ejemplo:

• Analizador de C# para Linux y macOS;
• complemento para Rider;
• Nuevo modo de verificación de lista de archivos.

Modo de verificación de lista de archivos

Anteriormente, para poder comprobar ciertos archivos, era necesario pasar un .xml con una lista de archivos al analizador. Pero como esto no es muy conveniente, agregamos la capacidad de transferir .txt, lo que hace la vida muy simple.

Para verificar archivos específicos, debe especificar la bandera --archivos fuente (-f) y transfiera .txt con una lista de archivos. Se parece a esto:

pvs-studio-dotnet -t path/to/solution.sln -f fileList.txt -o project.json

Si está interesado en configurar la verificación de confirmación o las solicitudes de extracción, también puede hacerlo usando este modo. La diferencia estará en obtener una lista de archivos para analizar y dependerá de qué sistemas estés utilizando.

El principio de comprobar una solicitud de fusión.

La esencia principal de la verificación es garantizar que los problemas detectados por el analizador durante la fusión no caigan en la categoría dominar rama. Tampoco queremos analizar todo el proyecto cada vez. Además, al fusionar ramas, tenemos una lista de archivos modificados. Por lo tanto, sugiero agregar una verificación de solicitud de fusión.

Así es como se ve una solicitud de fusión antes de implementar un analizador estático:

Es decir, todos los errores que había en la rama. cambios, se moverá a la rama maestra. Como no queremos esto, agregamos análisis y ahora el diagrama se ve así:

analizando cambios2 y, si no hay errores, aceptamos la solicitud de fusión, en caso contrario la rechazamos.

Por cierto, si está interesado en analizar confirmaciones y solicitudes de extracción para C/C++, puede leer sobre ello. aquí.

GitLab

GitLab es una herramienta de ciclo de vida de DevOps basada en web de código abierto que proporciona un sistema de gestión de repositorio de código para Git con su propia wiki, sistema de seguimiento de problemas, proceso de CI/CD y otras características.

Antes de comenzar a analizar las solicitudes de fusión, debe registrarse y cargar su proyecto. Si no sabes cómo hacer esto, te sugiero Artículo mi colega.

Nota. El método de configuración del entorno que se describe a continuación es uno de los posibles. El objetivo es mostrar los pasos para configurar el entorno necesario para el análisis y ejecutar el analizador. Quizás en su caso sería más óptimo separar las etapas de preparación del entorno (agregar repositorios, instalar un analizador) y análisis: por ejemplo, preparar imágenes de Docker con el entorno necesario y utilizarlas, o algún otro método.

Para comprender mejor lo que sucederá ahora, sugiero mirar el siguiente diagrama:

El analizador requiere .NET Core SDK 3 para funcionar, por lo que antes de instalar el analizador debe agregar los repositorios de Microsoft desde donde se instalarán las dependencias necesarias para el analizador. Agregar repositorios de Microsoft para varias distribuciones de Linux descrito en el documento correspondiente.

Para instalar PVS-Studio a través del administrador de paquetes, también deberá agregar los repositorios de PVS-Studio. La adición de repositorios para diferentes distribuciones se describe con más detalle en sección relevante de la documentación.

El analizador requiere una clave de licencia para funcionar. Puede obtener una licencia de prueba en página de descarga del analizador.

Nota. Tenga en cuenta que el modo de funcionamiento descrito (análisis de solicitudes de fusión) requiere una licencia Enterprise. Por tanto, si quieres probar este modo de funcionamiento, no olvides indicar en el campo “Mensaje” que necesitas una licencia Enterprise.

Si se produce una solicitud de fusión, solo necesitamos analizar la lista de archivos modificados; de lo contrario, analizamos todos los archivos. Después del análisis, necesitamos convertir los registros al formato que necesitamos.

Ahora que tienes el algoritmo de trabajo ante tus ojos, puedes pasar a escribir un guión. Para hacer esto, necesita cambiar el archivo. .gitlab-ci.yml o, si no existe, créelo. Para crearlo, debe hacer clic en el nombre de su proyecto -> Configurar CI/CD.

Ahora estamos listos para escribir el guión. Primero escribamos el código que instalará el analizador e ingresemos la licencia:

before_script:
  - apt-get update && apt-get -y install wget gnupg 

  - apt-get -y install git
  - wget https://packages.microsoft.com/config/debian/10/
packages-microsoft-prod.deb -O packages-microsoft-prod.deb
  - dpkg -i packages-microsoft-prod.deb
  - apt-get update
  - apt-get install apt-transport-https
  - apt-get update
  
  - wget -q -O - https://files.viva64.com/etc/pubkey.txt | apt-key add -
  - wget -O /etc/apt/sources.list.d/viva64.list
https://files.viva64.com/etc/viva64.list
  - apt-get update
  - apt-get -y install pvs-studio-dotnet

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY
  - dotnet restore "$CI_PROJECT_DIR"/Test/Test.sln

Dado que la instalación y activación deben ocurrir antes que todos los demás scripts, usamos una etiqueta especial antes_guion. Déjame explicarte un poco este fragmento.

Preparación para instalar el analizador:

  - wget https://packages.microsoft.com/config/debian/10/
packages-microsoft-prod.deb -O packages-microsoft-prod.deb
  - dpkg -i packages-microsoft-prod.deb
  - apt-get update
  - apt-get install apt-transport-https
  - apt-get update

Agregar repositorios y analizadores de PVS-Studio:

  - wget -q -O - https://files.viva64.com/etc/pubkey.txt | apt-key add -
  - wget -O /etc/apt/sources.list.d/viva64.list
https://files.viva64.com/etc/viva64.list
  - apt-get update
  - apt-get -y install pvs-studio-dotnet

Activación de licencia:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NOMBRE - Nombre de usuario.

$PVS_KEY - clave de producto.

Recuperar dependencias del proyecto donde $CI_PROJECT_DIR – ruta completa al directorio del proyecto:

  - dotnet restore "$CI_PROJECT_DIR"/Path/To/Solution.sln

Para un análisis correcto, el proyecto debe construirse exitosamente y sus dependencias deben restaurarse (por ejemplo, se deben descargar los paquetes NuGet necesarios).

Puede configurar variables de entorno que contengan información de licencia haciendo clic en Fijar, y después - en CI/CD.

En la ventana que se abre, busque el artículo. Variables, haz clic en el botón de la derecha Expandir y agregar variables. El resultado debería verse así:

Ahora puedes pasar al análisis. Primero, agreguemos un script para un análisis completo. a la bandera -t pasamos el camino a la solución a la bandera. -o escriba la ruta al archivo en el que se escribirán los resultados del análisis. También nos interesa el código de retorno. En este caso, nos interesa que la operación se detenga cuando el código de retorno contenga información de que se emitieron advertencias durante el análisis. Así es como se ve este fragmento:

job:
  script:
  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -o 
PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi

Los códigos de retorno funcionan según el principio de una máscara de bits. Por ejemplo, si se emitieron advertencias como resultado del análisis, entonces el código de retorno será igual a 8. Si la licencia vence dentro de un mes, entonces el código de retorno será igual a 4. Si se detectaron errores durante el análisis, y la licencia caduca dentro de un mes, el código de retorno, se escribirán ambos valores: sume los números y obtenga el código de retorno final: 8+4=12. Por tanto, al comprobar los bits correspondientes, se puede obtener información sobre varios estados durante el análisis. Los códigos de retorno se describen con más detalle en la sección "Códigos de retorno de pvs-studio-dotnet (Linux/macOS)" del documento "Verificación de proyectos de Visual Studio/MSBuild/.NET Core desde la línea de comando usando PVS-Studio".

En este caso, nos interesan todos los códigos de retorno donde aparece 8.

  - exit_code=$((($exit_code & 8)/8))

Recibiremos 1 cuando el código de retorno contenga el bit del número que nos interesa, en caso contrario recibiremos 0.

Es hora de agregar análisis de solicitudes de fusión. Antes de hacer esto, preparemos un lugar para el guión. Necesitamos que se ejecute solo cuando se produzca una solicitud de fusión. Se parece a esto:

merge:
  script:
  only:
  - merge_requests

Pasemos al guión en sí. Me enfrenté al hecho de que la máquina virtual no sabe nada sobre origen / maestro. Así que ayudémosla un poco:

  - git fetch origin

Ahora obtenemos la diferencia entre las ramas y guardamos el resultado en txt archivo:

  - git diff --name-only origin/master $CI_COMMIT_SHA > pvs-fl.txt

Donde $CI_COMMIT_SHA – hash del último compromiso.

A continuación, comenzamos a analizar la lista de archivos usando la bandera. -f. Le transferimos el archivo .txt recibido previamente. Bueno, por analogía con el análisis completo, nos fijamos en los códigos de retorno:

  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -f 
pvs-fl.txt -o PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi

El script completo para verificar una solicitud de fusión se verá así:

merge:
  script:
  - git fetch origin
  - git diff --name-only origin/master $CI_COMMIT_SHA > pvs-fl.txt
  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -f 
pvs-fl.txt -o PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi
  only:
  - merge_requests

Todo lo que queda es agregar la conversión de registros después de que se hayan procesado todos los scripts. Usamos la etiqueta después_script y utilidad convertidor-plog:

after_script:
  - plog-converter -t html -o eLog ./PVS-Studio.json

Utilidad convertidor-plog es un proyecto de código abierto que se utiliza para convertir informes de errores del analizador en varios formatos, como HTML. Se proporciona una descripción más detallada de la utilidad en la subsección "Utilidad Plog Converter". sección relevante de la documentación.

Por cierto, si desea trabajar cómodamente con informes .json localmente desde el IDE, le sugiero nuestro Programas para piloto IDE. Su uso se describe con más detalle en documento relevante.

Para mayor comodidad, aquí está. .gitlab-ci.yml entero:

image: debian

before_script:
  - apt-get update && apt-get -y install wget gnupg 

  - apt-get -y install git
  - wget https://packages.microsoft.com/config/debian/10/
packages-microsoft-prod.deb -O packages-microsoft-prod.deb
  - dpkg -i packages-microsoft-prod.deb
  - apt-get update
  - apt-get install apt-transport-https
  - apt-get update
  
  - wget -q -O - https://files.viva64.com/etc/pubkey.txt | apt-key add -
  - wget -O /etc/apt/sources.list.d/viva64.list
https://files.viva64.com/etc/viva64.list
  - apt-get update
  - apt-get -y install pvs-studio-dotnet

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY
  - dotnet restore "$CI_PROJECT_DIR"/Test/Test.sln

merge:
  script:
  - git fetch origin
  - git diff --name-only origin/master $CI_COMMIT_SHA > pvs-fl.txt
  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -f 
pvs-fl.txt -o PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi
  only:
  - merge_requests

job:
  script:
  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -o 
PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi
  
after_script:
  - plog-converter -t html -o eLog ./PVS-Studio.json

Una vez que haya agregado todo al archivo, haga clic en Cometer cambios. Para ver que todo está correcto ve a CI / CD -> Pipelines -> Correr. Se abrirá una ventana de máquina virtual, al final de la cual debería aparecer lo siguiente:

sierra Trabajo exitoso - éxito, todo está bien. Ahora puedes probar lo que has hecho.

Ejemplos de trabajo

Para un ejemplo de trabajo, creemos un proyecto simple (en dominar) que contendrá varios archivos. Después de eso, en otra rama cambiaremos solo un archivo e intentaremos realizar una solicitud de fusión.

Consideremos dos casos: cuando el archivo modificado contiene un error y cuando no. Primero, un ejemplo con un error.

Digamos que hay un archivo en la rama maestra. Program.cs, que no contiene errores, pero en otra rama el desarrollador agregó código erróneo y quiere realizar una solicitud de fusión. El tipo de error que cometió no es tan importante, lo principal es que existe. Por ejemplo, el operador olvidó lanzar (Sí, tan equivocado):

void MyAwesomeMethod(String name)
{
  if (name == null)
    new ArgumentNullException(....);
  // do something
  ....
}

Veamos el resultado de analizar un ejemplo con un error. Además, para asegurarme de que solo se analizó un archivo, agregué la bandera -r a la línea de lanzamiento de pvs-studio-dotnet:

Vemos que el analizador encontró un error y no permitió fusionar ramas.

Revisemos el ejemplo sin errores. Corrigiendo el código:

void MyAwesomeMethod(String name)
{
  if (name == null)
    throw new ArgumentNullException(....);
  // do something
  ....
}

Resultados del análisis de la solicitud de fusión:

Como podemos ver, no se encontraron errores y la ejecución de la tarea fue exitosa, que es lo que queríamos verificar.

Conclusión

Eliminar el código incorrecto antes de fusionar ramas es muy conveniente y agradable. Entonces, si está utilizando CI/CD, intente incorporar un analizador estático para verificar. Además, esto se hace de forma bastante sencilla.

Gracias por su atención.

Si desea compartir este artículo con una audiencia de habla inglesa, utilice el enlace de traducción: Nikolay Mironov. Análisis de solicitudes de fusión en GitLab usando PVS-Studio para C#.

Fuente: habr.com