🥇Análise de solicitações de merge no GitLab usando PVS-Studio para C#

Ama o GitLab e odeia bugs? Quer melhorar a qualidade do seu código-fonte? Então você veio ao lugar certo. Hoje vamos falar sobre como configurar o analisador PVS-Studio C# para verificar solicitações de mesclagem. Tenha um clima de unicórnio e boa leitura para todos.

Estúdio PVS é uma ferramenta para identificar erros e possíveis vulnerabilidades no código-fonte de programas escritos em C, C++, C# e Java. Funciona em sistemas de 64 bits no Windows, Linux e macOS. Pode analisar código projetado para plataformas ARM incorporadas e de 32 bits, 64 bits.

Aliás, lançamos o PVS-Studio 7.08, no qual fizemos muitas coisas interessante. Por exemplo:

Analisador C# para Linux e macOS;
plugin para Rider;
novo modo de verificação de lista de arquivos.

Modo de verificação da lista de arquivos

Anteriormente, para verificar determinados arquivos, era necessário passar um .xml com uma lista de arquivos para o analisador. Mas como isso não é muito conveniente, adicionamos a capacidade de transferir .txt, o que torna a vida muito simples.

Para verificar arquivos específicos, você deve especificar o sinalizador --Arquivos Fonte (-f) e transfira .txt com uma lista de arquivos. Se parece com isso:

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

Se estiver interessado em configurar verificação de commit ou solicitações pull, você também pode fazer isso usando este modo. A diferença estará em obter uma lista de arquivos para analisar e dependerá de quais sistemas você está usando.

O princípio de verificar uma solicitação de mesclagem

A principal essência da verificação é garantir que os problemas detectados pelo analisador durante a fusão não caiam no dominar filial. Também não queremos analisar todo o projeto todas as vezes. Além disso, ao mesclar ramificações, temos uma lista de arquivos alterados. Portanto, sugiro adicionar uma verificação de solicitação de mesclagem.

Esta é a aparência de uma solicitação de mesclagem antes de implementar um analisador estático:

Ou seja, todos os erros que estavam no branch alterar, irá para o branch master. Como não queremos isso, adicionamos análise e agora o diagrama fica assim:

Analisando mudanças 2 e, se não houver erros, aceitamos a solicitação de mesclagem, caso contrário a rejeitamos.

A propósito, se você estiver interessado em analisar commits e pull requests para C/C++, então você pode ler sobre isso aqui.

GitLab

GitLab é uma ferramenta de ciclo de vida DevOps baseada na web de código aberto que fornece um sistema de gerenciamento de repositório de código para Git com seu próprio wiki, sistema de rastreamento de problemas, pipeline de CI/CD e outros recursos.

Antes de começar a analisar solicitações de mesclagem, você precisa registrar e fazer upload do seu projeto. Se você não sabe como fazer isso, sugiro статью meu colega.

Nota. O método de configuração do ambiente descrito a seguir é um dos possíveis. O objetivo é mostrar os passos para configurar o ambiente necessário para análise e lançamento do analisador. Talvez no seu caso fosse mais ideal separar as etapas de preparação do ambiente (adicionar repositórios, instalar um analisador) e análise: por exemplo, preparar imagens Docker com o ambiente necessário e utilizá-las, ou algum outro método.

Para entender melhor o que acontecerá agora, sugiro observar o diagrama a seguir:

O analisador requer o .NET Core SDK 3 para funcionar, portanto, antes de instalar o analisador, você precisa adicionar os repositórios da Microsoft a partir dos quais as dependências necessárias para o analisador serão instaladas. Adicionando repositórios Microsoft para várias distribuições Linux descrito no documento correspondente.

Para instalar o PVS-Studio através do gerenciador de pacotes, você também precisará adicionar os repositórios do PVS-Studio. A adição de repositórios para diferentes distribuições é descrita com mais detalhes em seção relevante da documentação.

O analisador requer uma chave de licença para funcionar. Você pode obter uma licença de teste em página de download do analisador.

Nota. Observe que o modo de operação descrito (análise de solicitações de mesclagem) requer uma licença Enterprise. Portanto, se quiser experimentar este modo de funcionamento, não esqueça de indicar no campo “Mensagem” que necessita de uma licença Enterprise.

Se ocorrer uma solicitação de mesclagem, precisamos apenas analisar a lista de arquivos alterados, caso contrário, analisamos todos os arquivos. Após a análise, precisamos converter os logs para o formato que necessitamos.

Agora, tendo o algoritmo de trabalho diante de seus olhos, você pode passar a escrever um roteiro. Para fazer isso, você precisa alterar o arquivo .gitlab-ci.yml ou, se não existir, crie-o. Para criá-lo, você precisa clicar no nome do seu projeto -> Configurar CI/CD.

Agora estamos prontos para escrever o script. Vamos primeiro escrever o código que irá instalar o analisador e inserir a licença:

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

Como a instalação e a ativação devem ocorrer antes de todos os outros scripts, usamos um rótulo especial script_antes. Deixe-me explicar um pouco esse fragmento.

Preparando para instalar o analisador:

  - 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

Adicionando repositórios e analisador 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

Ativação da licença:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME - Nome de usuário.

$PVS_KEY - Chave do produto.

Recuperando dependências do projeto onde $CI_PROJECT_DIR – caminho completo para o diretório do projeto:

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

Para uma análise correta, o projeto deve ser compilado com sucesso e suas dependências devem ser restauradas (por exemplo, os pacotes NuGet necessários devem ser baixados).

Você pode definir variáveis de ambiente contendo informações de licença clicando em Configuração, e depois - em CI/CD.

Na janela que se abre, encontre o item Variáveis, clique no botão à direita Expandir e adicione variáveis. O resultado deve ficar assim:

Agora você pode passar para a análise. Primeiro, vamos adicionar um script para uma análise completa. Para a bandeira -t passamos o caminho para a solução da bandeira -o escreva o caminho para o arquivo no qual os resultados da análise serão gravados. Também estamos interessados no código de retorno. Neste caso, estamos interessados que a operação seja interrompida quando o código de retorno contiver a informação de que foram emitidos avisos durante a análise. Esta é a aparência deste 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

Os códigos de retorno funcionam segundo o princípio de uma máscara de bits. Por exemplo, se avisos foram emitidos como resultado da análise, o código de retorno será igual a 8. Se a licença expirar dentro de um mês, o código de retorno será igual a 4. Se forem detectados erros durante a análise, e a licença expirar dentro de um mês, o código retornará, ambos os valores serão escritos: some os números e obtenha o código de retorno final - 8+4=12. Assim, ao verificar os bits correspondentes, informações sobre vários estados podem ser obtidas durante a análise. Os códigos de retorno são descritos com mais detalhes na seção "Códigos de retorno pvs-studio-dotnet (Linux/macOS)" do documento "Verificando projetos Visual Studio/MSBuild/.NET Core na linha de comando usando PVS-Studio".

Neste caso, estamos interessados em todos os códigos de retorno onde aparece 8.

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

Receberemos 1 quando o código de retorno contiver o bit do número que nos interessa, caso contrário receberemos 0.

É hora de adicionar análise de solicitação de mesclagem. Antes de fazermos isso, vamos preparar um local para o roteiro. Precisamos que ele seja executado apenas quando ocorrer uma solicitação de mesclagem. Se parece com isso:

merge:
  script:
  only:
  - merge_requests

Vamos passar para o script em si. Me deparei com o fato de que a máquina virtual não sabe nada sobre origem / mestre. Então vamos ajudá-la um pouco:

  - git fetch origin

Agora pegamos a diferença entre os ramos e salvamos o resultado em txt arquivo:

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

Onde $CI_COMMIT_SHA – hash do último commit.

A seguir, começamos a analisar a lista de arquivos usando o sinalizador -f. Transferimos para ele o arquivo .txt recebido anteriormente. Bem, por analogia com a análise completa, olhamos os 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

O script completo para verificar uma solicitação de mesclagem será semelhante a este:

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

Tudo o que resta é adicionar a conversão de log depois que todos os scripts forem processados. Usamos o rótulo pós_script e utilidade conversor plog:

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

Utilitário conversor plog é um projeto de código aberto usado para converter relatórios de erros do analisador em vários formatos, como HTML. Uma descrição mais detalhada do utilitário é fornecida na subseção "Utilitário Plog Converter" seção relevante da documentação.

A propósito, se você quiser trabalhar convenientemente com relatórios .json localmente a partir do IDE, sugiro nosso Plugin para IDE Rider. Seu uso é descrito com mais detalhes em documento relevante.

Por conveniência, aqui está .gitlab-ci.yml na íntegra:

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

Depois de adicionar tudo ao arquivo, clique em Confirmar as alterações. Para verificar se está tudo correto, acesse CI / CD -> Dutos -> Corrida. Uma janela da máquina virtual será aberta, ao final da qual deverá haver o seguinte:

viu Trabalho bem-sucedido - sucesso, está tudo bem. Agora você pode testar o que fez.

Exemplos de trabalho

Para um exemplo de trabalho, vamos criar um projeto simples (em dominar) que conterá vários arquivos. Depois disso, em outra branch iremos alterar apenas um arquivo e tentar fazer uma solicitação de merge.

Vamos considerar dois casos: quando o arquivo modificado contém um erro e quando não contém. Primeiro, um exemplo com erro.

Digamos que haja um arquivo no branch master Programa.cs, que não contém erros, mas em outro branch o desenvolvedor adicionou código errado e deseja fazer uma solicitação de mesclagem. Que tipo de erro ele cometeu não é tão importante, o principal é que exista. Por exemplo, a operadora esqueceu jogar (Sim, tão errado):

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

Vejamos o resultado da análise de um exemplo com erro. Além disso, para ter certeza de que apenas um arquivo foi analisado, adicionei o sinalizador -r para a linha de lançamento do pvs-studio-dotnet:

Vemos que o analisador encontrou um erro e não permitiu a fusão de ramificações.

Vamos verificar o exemplo sem erro. Corrigindo o código:

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

Mesclar resultados da análise da solicitação:

Como podemos ver, nenhum erro foi encontrado e a execução da tarefa foi bem-sucedida, que é o que queríamos verificar.

Conclusão

Eliminar códigos incorretos antes de mesclar ramificações é muito conveniente e agradável. Portanto, se você estiver usando CI/CD, tente incorporar um analisador estático para verificar. Além disso, isso é feito de forma bastante simples.

Obrigado por sua atenção.

Se você quiser compartilhar este artigo com um público que fala inglês, use o link de tradução: Nikolay Mironov. Análise de solicitações de mesclagem no GitLab usando PVS-Studio para C#.

Fonte: habr.com

Análise de solicitações de mesclagem no GitLab usando PVS-Studio para C#

Modo de verificação da lista de arquivos

O princípio de verificar uma solicitação de mesclagem

GitLab

Exemplos de trabalho

Conclusão

Adicionar um comentário cancelar resposta