🥇Analisi delle merge request in GitLab con PVS-Studio per C#

Ami GitLab e odi gli errori? Vuoi migliorare la qualità del codice sorgente? Allora sei nel posto giusto. Oggi ti mostreremo come configurare l'analizzatore C# PVS-Studio per controllare le merge request. Buona lettura!

PVS-Studio PVS-Studio è uno strumento per rilevare errori e potenziali vulnerabilità nel codice sorgente di programmi scritti nei linguaggi C, C++, C# e Java. Funziona su sistemi a 64 bit su Windows, Linux e macOS. Può analizzare codice destinato a piattaforme ARM a 32 bit, 64 bit e embedded.

A proposito, abbiamo rilasciato PVS-Studio 7.08, in cui abbiamo fatto molte novità interessanti. Ad esempio:

analizzatore C# per Linux e macOS;
plugin per Rider;
nuova modalità di controllo dell'elenco dei file.

Modalità di controllo dell'elenco dei file

In precedenza, per controllare file specifici, era necessario fornire all'analizzatore un .xml con l'elenco dei file. Ma poiché questo non era molto comodo, abbiamo aggiunto la possibilità di fornire un .txt, il che semplifica notevolmente la vita.

Per controllare file specifici, è necessario specificare il flag --sourceFiles (-f) e fornire un .txt con l'elenco dei file. Si presenta nel modo seguente:

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

Se sei interessato a configurare la verifica dei commit o delle pull request, puoi farlo utilizzando questa modalità. La differenza consiste nel ricevere un elenco di file da analizzare e dipenderà dai sistemi che utilizzi.

Principio di verifica delle merge request

L'essenza della verifica è garantire che i problemi rilevati dall'analizzatore non entrino nella master branch. Non vogliamo nemmeno analizzare l'intero progetto ogni volta. Inoltre, durante la fusione dei branch abbiamo un elenco di file modificati. Propongo quindi di aggiungere la verifica delle merge request.

Ecco come appare la merge request prima dell'implementazione dell'analizzatore statico:

Cioè, tutti gli errori presenti nel branch changes, passeranno al branch master. Poiché non ci piacerebbe che ciò accadesse, aggiungiamo l'analisi, e ora lo schema appare come segue:

Analizziamo changes2 e, se non ci sono errori, accettiamo la merge request, altrimenti la rifiutiamo.

A proposito, se sei interessato all'analisi dei commit e delle pull request per C/C++, puoi leggere a riguardo. qui.

GitLab

GitLab — strumento web per il ciclo di vita DevOps con codice sorgente aperto, che offre un sistema di gestione dei repository Git con una wiki integrata, un sistema di tracciamento degli errori, una pipeline CI/CD e altre funzionalità.

Prima di procedere con l'analisi delle merge request, è necessario registrarsi e caricare il proprio progetto. Se non sai come farlo, ti consiglio di articolo un mio collega.

Nota. Il metodo di configurazione dell'ambiente descritto di seguito è solo uno dei possibili. L'obiettivo è mostrare i passaggi per configurare l'ambiente necessario per l'analisi e avviare l'analizzatore. Potrebbe essere più ottimale nel tuo caso separare le fasi di preparazione dell'ambiente (aggiunta di repository, installazione dell'analizzatore) e analisi: ad esempio, preparando immagini Docker con l'ambiente necessario e utilizzandole o con un altro metodo.

Per comprendere meglio cosa accadrà, ti propongo di dare un'occhiata al seguente schema:

Per far funzionare l'analizzatore è necessario il .NET Core SDK 3, quindi prima di installare l'analizzatore è necessario aggiungere i repository Microsoft da cui verranno installate le dipendenze necessarie per l'analizzatore. Aggiunta dei repository Microsoft per diverse distribuzioni Linux è descritto nel documento corrispondente.

Per installare PVS-Studio tramite un gestore di pacchetti sarà anche necessario aggiungere i repository di PVS-Studio. L'aggiunta dei repository per diverse distribuzioni è descritta più dettagliatamente in sezione corrispondente della documentazione.

Per far funzionare l'analizzatore è necessaria una chiave di licenza. È possibile ottenere una licenza di prova su pagina di download dell'analizzatore.

Nota. Si prega di notare che per la modalità di funzionamento descritta (analisi delle merge request) è necessaria una licenza Enterprise. Pertanto, se desideri provare questa modalità di lavoro, non dimenticare di indicare nel campo "Messaggio" che hai bisogno proprio di una licenza Enterprise.

Se si verifica una merge request, sarà necessario analizzare solo l'elenco dei file modificati, altrimenti analizziamo tutti i file. Dopo l'analisi bisogna convertire i log nel formato necessario.

Ora che abbiamo davanti l'algoritmo di funzionamento, possiamo procedere con la scrittura dello script. Per farlo, è necessario modificare il file .gitlab-ci.yml o, se non esiste, crearne uno. Per crearlo, bisogna cliccare sul nome del vostro progetto -> Imposta CI/CD.

Adesso siamo pronti per scrivere lo script. Iniziamo scrivendo il codice che installerà l'analizzatore e inserirà la licenza:

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

Poiché l'installazione e l'attivazione devono avvenire prima di tutti gli altri script, utilizziamo un'etichetta speciale before_script. Permettetemi di chiarire questo frammento.

Preparazione per l'installazione dell'analizzatore:

  - 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

Aggiunta dei repository PVS-Studio e dell'analizzatore:

  - 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

Attivazione della licenza:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME — nome utente.

$PVS_KEY — chiave del prodotto.

Ripristino delle dipendenze del progetto, dove $CI_PROJECT_DIR – percorso completo alla directory del progetto:

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

Per un'analisi corretta, il progetto deve compilarsi con successo e le sue dipendenze devono essere state ripristinate (ad esempio, è necessario caricare i pacchetti NuGet richiesti).

È possibile impostare le variabili di ambiente contenenti informazioni sulla licenza facendo clic su Impostazione, e poi su CI / CD.

Nella finestra che si apre, troviamo l'opzione Variabili, a destra clicchiamo sul pulsante Espandi e aggiungiamo le variabili. Il risultato dovrebbe essere il seguente:

Ora possiamo procedere all'analisi. Iniziamo aggiungendo uno script per l'analisi completa. Nel flag -t passiamo il percorso della soluzione, nel flag -o Scriviamo il percorso del file in cui saranno registrati i risultati dell'analisi. Ci interessa anche il codice di ritorno. In questo caso, è importante che il lavoro si fermi quando il codice di ritorno contiene informazioni che indicano che durante l'analisi sono stati emessi avvisi. Ecco come appare questo frammento:

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

I codici di ritorno funzionano secondo il principio della maschera di bit. Ad esempio, se durante l'analisi sono stati emessi avvisi, il codice di ritorno sarà 8. Se la licenza scade entro un mese, il codice di ritorno sarà 4. Se durante l'analisi sono stati rilevati errori e la licenza scade entro un mese, nel codice di ritorno saranno registrati entrambi i valori: sommiamo i numeri e otteniamo il codice di ritorno finale — 8+4=12. In questo modo, controllando i bit corrispondenti, si possono ottenere informazioni su vari stati durante l'analisi. I codici di ritorno sono descritti più dettagliatamente nella sezione "Codici di ritorno pvs-studio-dotnet (Linux / macOS)" del documento "Controllo dei progetti Visual Studio / MSBuild / .NET Core dalla riga di comando con PVS-Studio".

In questo caso, siamo interessati a tutti i codici di ritorno contenenti 8.

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

Otterremo 1 quando il codice di ritorno contiene il bit che ci interessa, altrimenti otterremo 0.

È giunto il momento di aggiungere l'analisi della merge request. Prima di farlo, prepariamo il posto per lo script. Dobbiamo assicurarci che venga eseguito solo quando si verifica una merge request. Ecco come si presenta:

merge:
  script:
  only:
  - merge_requests

Passiamo allo script vero e proprio. Ho riscontrato che la macchina virtuale non conosce nulla riguardo origin/master. Pertanto, la aiutiamo un po':

  - git fetch origin

Ora otteniamo la differenza tra i rami e salviamo il risultato in txt file:

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

Dove $CI_COMMIT_SHA – l'hash dell'ultimo commit.

Successivamente, avviamo l'analisi dell'elenco dei file, utilizzando il flag -f. Passiamo il file .txt ottenuto in precedenza. E in modo simile all'analisi completa, controlliamo i codici di ritorno:

  - 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

Lo script completo per il controllo della merge request sarà così:

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

Rimane solo da aggiungere la conversione del log dopo l'esecuzione di tutti gli script. Utilizziamo l'etichetta after_script e l'utility plog-converter:

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

Utility plog-converter — è un progetto open source che viene utilizzato per convertire il report sugli errori dell'analizzatore in diverse forme, ad esempio, HTML. Una descrizione più dettagliata dell'utilità è fornita nella sotto-sezione "Utilità Plog Converter" della sezione corrispondente della documentazione.

A proposito, se desideri lavorare comodamente con il report .json localmente dall'IDE, ti propongo il nostro plugin per l'IDE Rider. Un'utilizzo più dettagliato è descritto nel documento corrispondente.

Per comodità ecco .gitlab-ci.yml completo:

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 volta aggiunto tutto nel file, premi su Commit changes. Per controllare se è tutto corretto, andiamo su CI/CD -> Pipeline -> Esecuzione. Si aprirà la finestra della macchina virtuale, alla fine della quale dovrebbe esserci il seguente messaggio:

Abbiamo visto Job succeeded – successo, tutto va alla grande. Ora possiamo anche testare quanto fatto.

Esempi di funzionamento

Per esempio, creiamo un progetto semplice (in master) in cui ci saranno diversi file. Dopo di che, in un altro ramo, modificheremo solo un file e tenteremo di fare una richiesta di unione.

Consideriamo due casi: quando il file modificato contiene un errore e quando non ne contiene. Iniziamo con un esempio con errore.

Supponiamo che nel ramo master ci sia un file Program.cs, che non contiene errori, mentre in un altro ramo lo sviluppatore ha aggiunto codice errato e vuole fare una richiesta di unione. Quale errore ha commesso esattamente non è così importante, l'importante è che ci sia. Ad esempio, ha dimenticato l'operatore throw (sì, è così che si sbagliano):

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

Esaminiamo il risultato dell'analisi dell'esempio con errore. Inoltre, per assicurarci che sia stato analizzato solo un file, ho aggiunto un flag -r alla riga di comando pvs-studio-dotnet:

Vediamo che l'analizzatore ha trovato un errore e non ha consentito l'unione dei rami.

Controlliamo l'esempio senza errore. Correggiamo il codice:

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

Risultati dell'analisi della richiesta di unione:

Come vediamo, non sono stati trovati errori e l'assegnazione è stata completata con successo, che era ciò che volevamo verificare.

Conclusione

Filtrare il codice scarso prima di unire i branch è estremamente utile e piacevole. Pertanto, se utilizzate CI/CD, provate a integrare un analizzatore statico per il controllo. Inoltre, è piuttosto semplice da implementare.

Grazie per l'attenzione.

Se desiderate condividere questo articolo con un pubblico anglofono, vi prego di utilizzare il link per la traduzione: Nikolay Mironov. Analisi delle merge request in GitLab utilizzando PVS-Studio per C#.

Fonte: habr.com