🥇Analiza żądań scalania w GitLab przy użyciu PVS-Studio dla C#

Kochasz GitLab i nienawidzisz błędów? Chcesz poprawić jakość swojego kodu źródłowego? Zatem trafiłeś we właściwe miejsce. Dziś dowiemy się jak skonfigurować analizator C# PVS-Studio do sprawdzania żądań scalania. Życzymy wszystkim nastroju jednorożca i miłej lektury.

Studio PVS to narzędzie służące do identyfikacji błędów i potencjalnych podatności w kodzie źródłowym programów napisanych w językach C, C++, C# i Java. Działa na systemach 64-bitowych Windows, Linux i macOS. Potrafi analizować kod zaprojektowany dla platform 32-bitowych, 64-bitowych i wbudowanych ARM.

Nawiasem mówiąc, wydaliśmy PVS-Studio 7.08, w którym zrobiliśmy wiele rzeczy ciekawy. Na przykład:

Analizator C# dla systemów Linux i macOS;
wtyczka do Ridera;
nowy tryb sprawdzania listy plików.

Tryb sprawdzania listy plików

Wcześniej, aby sprawdzić określone pliki, konieczne było przesłanie do analizatora pliku .xml z listą plików. Ponieważ jednak nie jest to zbyt wygodne, dodaliśmy możliwość przesyłania plików .txt, co bardzo ułatwia życie.

Aby sprawdzić określone pliki, należy określić flagę --pliki źródłowe (-f) i prześlij plik .txt z listą plików. To wygląda tak:

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

Jeśli jesteś zainteresowany konfiguracją sprawdzania zatwierdzeń lub żądań ściągnięcia, możesz to również zrobić w tym trybie. Różnica będzie polegać na uzyskaniu listy plików do analizy i będzie zależała od używanych systemów.

Zasada sprawdzania wniosku o połączenie

Główną istotą kontroli jest upewnienie się, że problemy wykryte przez analizator podczas łączenia nie wchodzą w zakres mistrz oddział. Nie chcemy też za każdym razem analizować całego projektu. Ponadto podczas łączenia oddziałów mamy listę zmienionych plików. Dlatego sugeruję dodanie kontroli żądania połączenia.

Tak wygląda żądanie scalania przed wdrożeniem analizatora statycznego:

Oznacza to wszystkie błędy, które wystąpiły w gałęzi zmiany, zostanie przeniesiony do gałęzi master. Ponieważ byśmy tego nie chcieli, dodajemy analizę i teraz diagram wygląda następująco:

Analizowanie zmiany 2 i jeśli nie ma błędów, akceptujemy prośbę o połączenie, w przeciwnym razie ją odrzucamy.

Przy okazji, jeśli interesuje Cię analiza zatwierdzeń i żądań ściągnięcia dla C/C++, możesz o tym przeczytać tutaj.

GitLab

GitLab to internetowe narzędzie cyklu życia DevOps o otwartym kodzie źródłowym, które zapewnia system zarządzania repozytorium kodu dla Git z własną wiki, systemem śledzenia problemów, potokiem CI/CD i innymi funkcjami.

Zanim zaczniesz analizować prośby o połączenie, musisz zarejestrować i przesłać swój projekt. Jeśli nie wiesz jak to zrobić, to sugeruję статью mój kolega.

Operacja. Opisany poniżej sposób konfiguracji środowiska jest jednym z możliwych. Celem jest pokazanie etapów konfiguracji środowiska niezbędnego do analizy i uruchomienia analizatora. Być może w Twoim przypadku bardziej optymalne byłoby rozdzielenie etapów przygotowania środowiska (dodanie repozytoriów, instalacja analizatora) i analizy: np. przygotowanie obrazów Dockera z niezbędnym środowiskiem i wykorzystanie ich lub inną metodą.

Aby lepiej zrozumieć, co się teraz stanie, sugeruję przyjrzenie się poniższemu diagramowi:

Analizator do działania wymaga pakietu .NET Core SDK 3, dlatego przed instalacją analizatora należy dodać repozytoria Microsoft, z których zostaną zainstalowane wymagane dla analizatora zależności. Dodawanie repozytoriów Microsoft dla różnych dystrybucji Linuksa opisane w odpowiednim dokumencie.

Aby zainstalować PVS-Studio za pośrednictwem menedżera pakietów, będziesz musiał także dodać repozytoria PVS-Studio. Dodawanie repozytoriów dla różnych dystrybucji opisano bardziej szczegółowo w odpowiednią sekcję dokumentacji.

Analizator do działania wymaga klucza licencyjnego. Licencję próbną można uzyskać pod adresem strona pobierania analizatora.

Operacja. Należy pamiętać, że opisywany tryb działania (analiza żądań połączenia) wymaga licencji Enterprise. Dlatego jeśli chcesz wypróbować ten tryb działania, nie zapomnij wskazać w polu „Wiadomość”, że potrzebujesz licencji Enterprise.

Jeśli pojawi się żądanie połączenia, wystarczy przeanalizować listę zmienionych plików, w przeciwnym razie przeanalizujemy wszystkie pliki. Po analizie musimy przekonwertować logi do potrzebnego nam formatu.

Teraz, mając przed oczami algorytm pracy, możesz przejść do pisania scenariusza. Aby to zrobić, musisz zmienić plik .gitlab-ci.yml lub, jeśli nie istnieje, utwórz go. Aby go utworzyć, kliknij nazwę swojego projektu -> Skonfiguruj CI/CD.

Teraz jesteśmy gotowi do napisania scenariusza. Napiszmy najpierw kod, który zainstaluje analizator i wprowadzimy licencję:

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

Ponieważ instalacja i aktywacja muszą nastąpić przed wszystkimi innymi skryptami, używamy specjalnej etykiety przed_skryptem. Pozwólcie, że wyjaśnię trochę ten fragment.

Przygotowanie do montażu analizatora:

  - 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

Dodawanie repozytoriów i analizatora 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

Aktywacja licencji:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME - Nazwa użytkownika.

$PVS_KEY - klucz produktu.

Odzyskiwanie zależności projektu gdzie $CI_PROJECT_DIR – pełna ścieżka do katalogu projektu:

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

Aby analiza była prawidłowa, projekt musi zostać pomyślnie zbudowany, a jego zależności muszą zostać odtworzone (na przykład należy pobrać niezbędne pakiety NuGet).

Klikając, możesz ustawić zmienne środowiskowe zawierające informacje o licencji Oprawa, i po - na CI/CD.

W oknie, które zostanie otwarte, znajdź przedmiot Zmienne, kliknij przycisk po prawej stronie Rozszerzać i dodaj zmienne. Wynik powinien wyglądać następująco:

Teraz możesz przejść do analizy. Najpierw dodajmy skrypt do pełnej analizy. Do flagi -t przekazujemy ścieżkę do rozwiązania flagi -o wpisz ścieżkę do pliku, w którym zostaną zapisane wyniki analizy. Interesuje nas również kod zwrotny. W tym przypadku interesuje nas zatrzymanie operacji, gdy w kodzie zwrotnym będzie informacja, że w trakcie analizy zostały wydane ostrzeżenia. Tak wygląda ten fragment:

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

Kody zwrotne działają na zasadzie maski bitowej. Przykładowo, jeśli w wyniku analizy zostały wydane ostrzeżenia, to kod powrotu będzie równy 8. Jeśli licencja wygaśnie w ciągu miesiąca, to kod powrotu będzie równy 4. Jeżeli w trakcie analizy wykryto błędy, a licencja wygaśnie za miesiąc, kod zwróci, zostaną zapisane obie wartości: zsumuj liczby i uzyskaj ostateczny kod powrotu - 8+4=12. Zatem sprawdzając odpowiednie bity, można w trakcie analizy uzyskać informacje o różnych stanach. Kody zwrotne opisano bardziej szczegółowo w sekcji „Kody zwrotne pvs-studio-dotnet (Linux / macOS)” dokumentu „Sprawdzanie projektów Visual Studio / MSBuild / .NET Core z wiersza poleceń przy użyciu PVS-Studio".

W tym przypadku interesują nas wszystkie kody powrotu, w których występuje liczba 8.

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

Otrzymamy 1, gdy w kodzie zwrotnym będzie znajdował się bit interesującej nas liczby, w przeciwnym wypadku otrzymamy 0.

Czas dodać analizę żądań połączenia. Zanim to zrobimy przygotujmy miejsce na scenariusz. Potrzebujemy, aby zostało wykonane tylko wtedy, gdy wystąpi żądanie scalania. To wygląda tak:

merge:
  script:
  only:
  - merge_requests

Przejdźmy do samego skryptu. Stanąłem przed faktem, że maszyna wirtualna nic nie wie pochodzenie/master. Pomóżmy jej więc trochę:

  - git fetch origin

Teraz otrzymujemy różnicę między gałęziami i zapisujemy wynik w txt plik:

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

Где $CI_COMMIT_SHA – skrót ostatniego zatwierdzenia.

Następnie zaczynamy analizować listę plików za pomocą flagi -f. Przenosimy do niego otrzymany wcześniej plik .txt. Cóż, analogicznie do pełnej analizy, patrzymy na kody powrotne:

  - 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

Kompletny skrypt sprawdzający żądanie scalania będzie wyglądał następująco:

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

Pozostaje tylko dodać konwersję dziennika po przetworzeniu wszystkich skryptów. Używamy etykiety po_skrypcie i użyteczność konwerter plogów:

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

Użyteczność konwerter plogów to projekt typu open source, który służy do konwertowania raportów o błędach analizatora składni na różne formy, takie jak HTML. Bardziej szczegółowy opis narzędzia znajduje się w podrozdziale „Narzędzie Plog Converter” odpowiednią sekcję dokumentacji.

Swoją drogą, jeśli chcesz wygodnie pracować z raportami .json lokalnie z IDE, to sugeruję nasz podłącz dla IDE Ridera. Jego zastosowanie opisano bardziej szczegółowo w Odpowiedni dokument.

Dla wygody, oto on .gitlab-ci.yml w pełni:

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

Po dodaniu wszystkiego do pliku kliknij Zatwierdź zmiany. Aby sprawdzić, czy wszystko jest w porządku, przejdź do CI / CD -> Rurociągi -> Bieganie. Otworzy się okno maszyny wirtualnej, na końcu którego powinno znajdować się:

piła Zadanie się powiodło - sukces, wszystko w porządku. Teraz możesz przetestować to, co zrobiłeś.

Przykłady pracy

Dla przykładu pracy utwórzmy prosty projekt (w formacie mistrz), który będzie zawierał kilka plików. Następnie w innym oddziale zmienimy tylko jeden plik i spróbujemy złożyć żądanie scalania.

Rozważmy dwa przypadki: kiedy zmodyfikowany plik zawiera błąd i kiedy go nie ma. Najpierw przykład z błędem.

Załóżmy, że w gałęzi master znajduje się plik Program.cs, który nie zawiera błędów, ale w innej gałęzi programista dodał błędny kod i chce złożyć żądanie scalania. Jaki błąd popełnił, nie jest tak ważny, najważniejsze, że istnieje. Na przykład operator zapomniał rzucać (Tak, bardzo źle):

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

Spójrzmy na wynik analizy przykładu z błędem. Aby mieć pewność, że przeanalizowano tylko jeden plik, dodałem flagę -r do linii uruchamiania pvs-studio-dotnet:

Widzimy, że analizator znalazł błąd i nie pozwolił na połączenie gałęzi.

Sprawdźmy przykład bez błędu. Poprawianie kodu:

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

Wyniki analizy żądań połączenia:

Jak widzimy, nie znaleziono żadnych błędów, a wykonanie zadania przebiegło pomyślnie, co chcieliśmy sprawdzić.

wniosek

Wyeliminowanie złego kodu przed połączeniem gałęzi jest bardzo wygodne i przyjemne. Jeśli więc używasz CI/CD, spróbuj osadzić analizator statyczny, aby to sprawdzić. Co więcej, odbywa się to po prostu.

Dziękuję za uwagę.

Jeśli chcesz udostępnić ten artykuł anglojęzycznej publiczności, skorzystaj z linku do tłumaczenia: Nikolay Mironov. Analiza żądań scalania w GitLab przy użyciu PVS-Studio dla C#.

Źródło: www.habr.com

Analiza żądań scalania w GitLab przy użyciu PVS-Studio dla C#

Tryb sprawdzania listy plików

Zasada sprawdzania wniosku o połączenie

GitLab

Przykłady pracy

wniosek

Dodaj komentarz Anuluj odpowiedź