C#용 PVS-Studio를 사용하여 GitLab에서 병합 요청 분석

GitLab을 좋아하고 버그를 싫어하시나요? 소스 코드의 품질을 향상시키고 싶으십니까? 그렇다면 당신은 올바른 장소에 왔습니다. 오늘은 PVS-Studio C# 분석기를 구성하여 병합 요청을 확인하는 방법을 알려드리겠습니다. 모두들 유니콘 기분을 갖고 행복한 독서를 하세요.

PVS-스튜디오 C, C++, C# 및 Java로 작성된 프로그램 소스 코드의 오류와 잠재적인 취약점을 식별하는 도구입니다. Windows, Linux 및 macOS의 64비트 시스템에서 작동합니다. 32비트, 64비트 및 임베디드 ARM 플랫폼용으로 설계된 코드를 분석할 수 있습니다.

그건 그렇고, 우리는 PVS-Studio 7.08을 출시했는데, 여기서 우리는 많은 일을 했습니다. 흥미로운. 예 :

• Linux 및 macOS용 C# 분석기;
• 라이더용 플러그인;
• 새로운 파일 목록 확인 모드.

파일 목록 확인 모드

이전에는 특정 파일을 확인하려면 파일 목록이 포함된 .xml을 분석기에 전달해야 했습니다. 하지만 이는 그다지 편리하지 않기 때문에 .txt를 전송하는 기능을 추가하여 생활을 매우 단순하게 만듭니다.

특정 파일을 확인하려면 플래그를 지정해야 합니다. --source파일 (-f) 파일 목록과 함께 .txt를 전송합니다. 다음과 같습니다.

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

커밋 확인 또는 풀 요청 설정에 관심이 있는 경우 이 모드를 사용하여 해당 작업을 수행할 수도 있습니다. 차이점은 분석할 파일 목록을 얻는 데 있으며 사용 중인 시스템에 따라 달라집니다.

병합 요청 확인 원칙

검사의 주요 본질은 병합 중에 분석기가 감지한 문제가 다음 단계에 속하지 않는지 확인하는 것입니다. 석사 나뭇가지. 또한 우리는 매번 전체 프로젝트를 분석하고 싶지 않습니다. 또한 브랜치를 병합하면 변경된 파일 목록이 표시됩니다. 따라서 병합 요청 확인을 추가하는 것이 좋습니다.

정적 분석기를 구현하기 전의 병합 요청은 다음과 같습니다.

즉, 브랜치에 있던 모든 오류가 변경, 마스터 브랜치로 이동합니다. 우리는 이것을 원하지 않기 때문에 분석을 추가합니다. 이제 다이어그램은 다음과 같습니다.

분석하는 변화2 오류가 없으면 병합 요청을 수락하고, 그렇지 않으면 거부합니다.

그런데 C/C++에 대한 커밋 및 풀 요청 분석에 관심이 있다면 이에 대해 읽어볼 수 있습니다. 여기에.

GitLab

GitLab Git용 코드 저장소 관리 시스템과 자체 위키, 문제 추적 시스템, CI/CD 파이프라인 및 기타 기능을 제공하는 오픈 소스 웹 기반 DevOps 수명 주기 도구입니다.

병합 요청 분석을 시작하기 전에 프로젝트를 등록하고 업로드해야 합니다. 어떻게 해야할지 모르신다면 추천해드려요 статью 내 동료.

주의. 아래에 설명된 환경 설정 방법은 가능한 방법 중 하나입니다. 분석에 필요한 환경을 설정하고 분석기를 시작하는 단계를 보여주는 것이 목표입니다. 아마도 귀하의 경우 환경 준비(리포지토리 추가, 분석기 설치) 단계와 분석 단계를 분리하는 것이 더 최적일 수 있습니다. 예를 들어 필요한 환경으로 Docker 이미지를 준비하고 사용하거나 다른 방법을 사용할 수 있습니다.

지금 무슨 일이 일어날지 더 잘 이해하려면 다음 다이어그램을 살펴보는 것이 좋습니다.

분석기가 작동하려면 .NET Core SDK 3이 필요하므로 분석기를 설치하기 전에 분석기에 필요한 종속성을 설치할 Microsoft 리포지토리를 추가해야 합니다. 다양한 Linux 배포판을 위한 Microsoft 리포지토리 추가 해당 문서에 설명되어 있음.

패키지 관리자를 통해 PVS-Studio를 설치하려면 PVS-Studio 리포지토리도 추가해야 합니다. 다양한 배포판에 대한 리포지토리 추가에 대한 자세한 내용은 문서의 관련 섹션.

분석기를 작동하려면 라이센스 키가 필요합니다. 다음에서 평가판 라이센스를 얻을 수 있습니다. 분석기 다운로드 페이지.

주의. 설명된 작업 모드(병합 요청 분석)에는 Enterprise 라이센스가 필요합니다. 따라서 이 작업 모드를 시도하려면 "메시지" 필드에 Enterprise 라이센스가 필요함을 표시하는 것을 잊지 마십시오.

병합 요청이 발생하면 변경된 파일 목록만 분석하면 되고, 그렇지 않으면 모든 파일을 분석하면 됩니다. 분석 후에는 로그를 필요한 형식으로 변환해야 합니다.

이제 작업 알고리즘을 눈앞에 두고 스크립트 작성으로 넘어갈 수 있습니다. 이렇게 하려면 파일을 변경해야 합니다. .gitlab-ci.yml 또는 존재하지 않는 경우 새로 만듭니다. 그것을 생성하려면 프로젝트 이름을 클릭해야 합니다 -> CI/CD 설정.

이제 스크립트를 작성할 준비가 되었습니다. 먼저 분석기를 설치하고 라이센스를 입력하는 코드를 작성해 보겠습니다.

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

설치와 활성화는 다른 모든 스크립트보다 먼저 이루어져야 하므로 특수 라벨을 사용합니다. before_script. 이 부분을 조금 설명하겠습니다.

분석기 설치 준비:

  - 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

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

라이센스 활성화:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME - 사용자 이름.

$PVS_KEY - 제품 키.

프로젝트 종속성을 복구하는 중 $CI_PROJECT_DIR – 프로젝트 디렉토리의 전체 경로:

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

올바른 분석을 위해서는 프로젝트가 성공적으로 빌드되어야 하며 해당 종속성을 복원해야 합니다(예: 필요한 NuGet 패키지를 다운로드해야 함).

클릭하면 라이센스 정보가 포함된 환경 변수를 설정할 수 있습니다. 환경, 그리고 이후 CI/CD.

열리는 창에서 항목을 찾으십시오. 변수, 오른쪽 버튼을 클릭하세요 펼치기 그리고 변수를 추가합니다. 결과는 다음과 같아야 합니다.

이제 분석으로 넘어갈 수 있습니다. 먼저 완전한 분석을 위해 스크립트를 추가해 보겠습니다. 깃발에 -t 플래그에 대한 솔루션 경로를 전달합니다. -o 분석 결과가 기록될 파일의 ​​경로를 작성합니다. 우리는 반환 코드에도 관심이 있습니다. 이 경우 분석 중에 경고가 발생했다는 정보가 반환 코드에 포함되면 작업이 중지되는 데 관심이 있습니다. 이 조각은 다음과 같습니다.

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

반환 코드는 비트 마스크 원칙에 따라 작동합니다. 예를 들어 분석 결과 경고가 발행된 경우 반환 코드는 8이 됩니다. 라이센스가 한 달 이내에 만료되면 반환 코드는 4가 됩니다. 분석 중에 오류가 감지된 경우 라이센스가 한 달 이내에 만료되면 코드가 반환되고 두 값이 모두 기록됩니다. 숫자를 더하고 최종 반환 코드인 8+4=12를 얻습니다. 따라서 해당 비트를 확인함으로써 분석 시 다양한 상태에 대한 정보를 얻을 수 있다. 반환 코드는 문서의 "pvs-studio-dotnet(Linux/macOS) 반환 코드" 섹션에 자세히 설명되어 있습니다.PVS-Studio를 사용하여 명령줄에서 Visual Studio/MSBuild/.NET Core 프로젝트 확인".

이 경우 8이 나타나는 모든 반환 코드에 관심이 있습니다.

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

반환 코드에 우리가 관심 있는 숫자의 비트가 포함되어 있으면 1을 받고, 그렇지 않으면 0을 받게 됩니다.

이제 병합 요청 분석을 추가할 차례입니다. 이 작업을 수행하기 전에 스크립트를 위한 장소를 준비합시다. 병합 요청이 발생할 때만 실행되어야 합니다. 다음과 같습니다.

merge:
  script:
  only:
  - merge_requests

스크립트 자체로 넘어 갑시다. 나는 가상 머신이 아무것도 모른다는 사실에 직면했습니다. 원산지 / 마스터. 그러니 그녀를 조금 도와주자:

  - git fetch origin

이제 우리는 분기 간의 차이를 얻고 결과를 다음 위치에 저장합니다. TXT 파일:

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

Где $CI_COMMIT_SHA – 마지막 커밋의 해시입니다.

다음으로 플래그를 사용하여 파일 목록 분석을 시작합니다. -f. 이전에 받은 .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

병합 요청을 확인하는 전체 스크립트는 다음과 같습니다.

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

남은 것은 모든 스크립트가 처리된 후 로그 변환을 추가하는 것입니다. 우리는 라벨을 사용합니다 after_script 유틸리티 플로그 변환기:

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

공익 사업 플로그 변환기 파서 오류 보고서를 HTML과 같은 다양한 형식으로 변환하는 데 사용되는 오픈 소스 프로젝트입니다. 유틸리티에 대한 자세한 설명은 "Plog 변환기 유틸리티" 하위 섹션에 나와 있습니다. 문서의 관련 섹션.

그런데 IDE에서 로컬로 .json 보고서를 편리하게 사용하려면 다음을 제안합니다. 플러그인 IDE 라이더용. 그 사용법은 다음 항목에 자세히 설명되어 있습니다. 관련 문서.

편의상 이렇습니다. .gitlab-ci.yml 전부:

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

파일에 모든 내용을 추가한 후 다음을 클릭하세요. 변경 사항 적용. 모든 것이 올바른지 확인하려면 다음으로 이동하십시오. CI / CD -> 파이프 라인 -> 달리는. 가상 머신 창이 열리고 마지막에는 다음이 표시됩니다.

봤다 작업 성공 - 성공, 모든 것이 괜찮습니다. 이제 수행한 작업을 테스트할 수 있습니다.

작업 예

작업의 예를 들어 간단한 프로젝트를 만들어 보겠습니다( 석사)에는 여러 파일이 포함됩니다. 그 후 다른 브랜치에서는 파일 하나만 변경하고 병합 요청을 시도합니다.

수정된 파일에 오류가 있는 경우와 오류가 없는 경우의 두 가지 경우를 고려해 보겠습니다. 먼저 오류가 있는 예입니다.

마스터 브랜치에 파일이 있다고 가정해 보겠습니다. 프로그램.cs, 여기에는 오류가 없지만 다른 브랜치에서 개발자가 잘못된 코드를 추가하여 병합 요청을 하려고 합니다. 그가 어떤 종류의 실수를 저질렀는지는 그다지 중요하지 않으며, 가장 중요한 것은 그것이 존재한다는 것입니다. 예를 들어, 교환원이 잊어버렸어요 던져 (예, 정말 틀렸어):

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

오류가 발생한 예제를 분석한 결과를 살펴보겠습니다. 또한 하나의 파일만 구문 분석되었는지 확인하기 위해 플래그를 추가했습니다. -r pvs-studio-dotnet 출시 라인:

분석기가 오류를 발견하여 브랜치 병합을 허용하지 않은 것을 확인했습니다.

오류 없이 예제를 확인해 보겠습니다. 코드 수정:

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

병합 요청 분석 결과:

보시다시피 오류가 발견되지 않았으며 작업 실행이 성공했는지 확인하고 싶었습니다.

결론

브랜치를 병합하기 전에 잘못된 코드를 제거하는 것은 매우 편리하고 즐겁습니다. 따라서 CI/CD를 사용하는 경우 정적 분석기를 내장하여 확인해보세요. 또한 이것은 매우 간단하게 수행됩니다.

관심을 가져 주셔서 감사합니다.

이 기사를 영어권 청중과 공유하려면 번역 링크인 Nikolay Mironov를 사용하십시오. C#용 PVS-Studio를 사용하여 GitLab에서 병합 요청 분석.

출처 : habr.com