PVS-Studio를 사용하여 Travis CI, Buddy 및 AppVeyor의 커밋 및 풀 요청 분석

Linux 및 macOS의 C 및 C++ 언어용 PVS-Studio 분석기 버전 7.04부터 지정된 파일 목록을 확인하는 테스트 옵션이 나타났습니다. 새 모드를 사용하면 커밋과 풀 요청을 확인하도록 분석기를 구성할 수 있습니다. 이 기사에서는 Travis CI, Buddy 및 AppVeyor와 같은 널리 사용되는 CI(지속적 통합) 시스템에서 GitHub 프로젝트의 변경된 파일 목록 확인을 설정하는 방법을 설명합니다.

파일 목록 확인 모드

PVS-스튜디오 C, C++, C# 및 Java로 작성된 프로그램 소스 코드의 오류와 잠재적인 취약점을 식별하는 도구입니다. Windows, Linux 및 macOS의 64비트 시스템에서 작동합니다.

Linux 및 macOS용 PVS-Studio 7.04 버전에는 소스 파일 목록을 확인하는 모드가 나타났습니다. 이는 빌드 시스템을 통해 파일을 생성할 수 있는 프로젝트에 적용됩니다. compile_commands.json. 분석기가 지정된 파일의 컴파일에 대한 정보를 추출하는 데 필요합니다. 빌드 시스템이 compile_commands.json 파일 생성을 지원하지 않는 경우 유틸리티를 사용하여 해당 파일을 생성해 볼 수 있습니다. 곰.

또한 파일 목록 확인 모드는 컴파일러 실행의 strace 추적 로그(pvs-studio-analyzer 추적)와 함께 사용할 수 있습니다. 이렇게 하려면 먼저 프로젝트의 전체 빌드를 수행하고 이를 추적하여 분석기가 검사 중인 모든 파일의 컴파일 매개변수에 대한 전체 정보를 수집하도록 해야 합니다.

그러나 이 옵션에는 심각한 단점이 있습니다. 실행할 때마다 전체 프로젝트의 전체 빌드 추적을 수행해야 하며, 이는 그 자체로 커밋을 빠르게 확인한다는 아이디어와 모순됩니다. 또는 추적 결과 자체를 캐시하는 경우 추적 후 소스 파일의 종속성 구조가 변경되면 분석기의 후속 실행이 완료되지 않을 수 있습니다(예: 소스 파일 중 하나에 새로운 #include가 추가됨).

따라서 커밋이나 풀 요청을 확인하기 위해 추적 로그와 함께 파일 목록 확인 모드를 사용하지 않는 것이 좋습니다. 커밋을 확인할 때 증분 빌드를 수행할 수 있는 경우 모드 사용을 고려하세요. 증분 분석.

분석을 위한 소스 파일 목록은 텍스트 파일로 저장되며 매개변수를 사용하여 분석기로 전달됩니다. -S:

pvs-studio-analyzer analyze ... -f build/compile_commands.json -S check-list.txt

이 파일은 파일에 대한 상대 또는 절대 경로를 지정하며 각각의 새 파일은 새 줄에 있어야 합니다. 분석을 위한 파일명뿐만 아니라 다양한 텍스트를 지정하는 것도 가능합니다. 분석기는 이것이 파일이 아니라는 것을 확인하고 해당 행을 무시합니다. 파일을 수동으로 지정한 경우 주석을 달 때 유용할 수 있습니다. 그러나 CI 분석 중에 파일 목록이 생성되는 경우가 많습니다. 예를 들어 이러한 파일은 커밋 또는 끌어오기 요청의 파일일 수 있습니다.

이제 이 모드를 사용하면 새 코드가 기본 개발 분기에 들어가기 전에 빠르게 확인할 수 있습니다. 스캐닝 시스템이 분석기 경고에 응답하도록 하기 위해 유틸리티는 플로그 변환기 플래그가 추가됨 --경고 표시:

plog-converter ... --indicate-warnings ... -o /path/to/report.tasks ...

이 플래그를 사용하면 분석기 보고서에 경고가 있는 경우 변환기가 XNUMX이 아닌 코드를 반환합니다. 반환 코드를 사용하면 사전 커밋 후크, 커밋 또는 끌어오기 요청을 차단할 수 있으며 생성된 분석기 보고서를 표시, 공유하거나 이메일로 보낼 수 있습니다.

메모. 처음 파일 목록 분석을 시작하면 전체 프로젝트가 분석됩니다. 분석기는 헤더 파일에 대한 프로젝트 소스 파일의 종속성 파일을 생성해야 합니다. C, C++ 파일을 분석하는 기능입니다. 앞으로는 종속성 파일을 캐시할 수 있으며 분석기에 의해 자동으로 업데이트됩니다. 증분 분석 모드를 사용하는 것보다 파일 목록 검사 모드를 사용할 때 커밋을 검사하면 개체 파일이 아닌 해당 파일만 캐시하면 된다는 이점이 있습니다.

풀 요청 분석의 일반 원칙

전체 프로젝트를 분석하려면 시간이 많이 걸리므로 특정 부분만 확인하는 것이 합리적입니다. 문제는 새 파일을 나머지 프로젝트 파일과 분리해야 한다는 것입니다.

두 개의 분기가 있는 커밋 트리의 예를 살펴보겠습니다.

커밋을 상상해 봅시다 A1 이미 테스트된 상당히 많은 양의 코드가 포함되어 있습니다. 조금 더 일찍 커밋에서 브랜치를 만들었습니다. A1 일부 파일을 변경했습니다.

물론 당신은 그 후에 A1 두 개의 커밋이 더 발생했지만 이것도 다른 브랜치의 합병이었습니다. 석사. 그리고 이제 때가 왔습니다. 핫픽스 준비가 된. 그래서 합병 요청이 나타났습니다 B3 и A3.

물론 합병 결과 전체를 확인하는 것도 가능하겠지만, 변경된 파일이 몇 개에 불과하기 때문에 시간이 너무 많이 걸리고 정당하지 않습니다. 따라서 변경된 것만 분석하는 것이 더 효율적이다.

이를 위해 마스터로 병합하려는 브랜치의 HEAD에 있는 브랜치 간의 차이점을 얻습니다.

git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list

$MERGE_BASE 나중에 자세히 살펴보겠습니다. 사실 모든 CI 서비스가 병합에 필요한 데이터베이스 정보를 제공하는 것은 아니므로 매번 이 데이터를 얻기 위한 새로운 방법을 찾아야 합니다. 이에 대해서는 아래에서 설명하는 각 웹 서비스에서 자세히 설명합니다.

그래서 우리는 브랜치 간의 차이점, 또는 변경된 파일 이름 목록을 얻었습니다. 이제 파일을 주어야 합니다 .pvs-pr.list (위의 출력을 여기로 리디렉션했습니다) 분석기로:

pvs-studio-analyzer analyze -j8 
                            -o PVS-Studio.log 
                            -S .pvs-pr.list

분석 후에는 로그 파일(PVS-Studio.log)을 읽기 쉬운 형식으로 변환해야 합니다.

plog-converter -t errorfile PVS-Studio.log --cerr -w

이 명령은 다음의 오류를 나열합니다. 표준 오류 (표준 오류 메시지 출력).

이제 우리는 오류를 표시할 뿐만 아니라 문제가 있는지 조립 및 테스트 서비스에 알려야 합니다. 이를 위해 변환기에 플래그가 추가되었습니다. -W (--경고 표시). 하나 이상의 분석기 경고가 있는 경우 유틸리티 반환 코드 플로그 변환기 2로 변경되어 CI 서비스에 풀 요청 파일에 잠재적인 오류가 있음을 알립니다.

트래비스 CI

구성은 파일로 이루어집니다. .travis.yml. 편의를 위해 파일에서 호출될 함수가 포함된 별도의 bash 스크립트에 모든 것을 넣는 것이 좋습니다. .travis.yml (bash 스크립트_이름.sh 함수_이름).

스크립트에 필요한 코드를 추가하겠습니다. 세게 때리다, 이렇게 하면 더 많은 기능을 얻을 수 있습니다. 섹션에서 설치 다음을 작성해 봅시다:

install:
  - bash .travis.sh travis_install

지침이 있는 경우 하이픈을 제거하여 해당 지침을 스크립트로 전송할 수 있습니다.

파일을 열어보자 .travis.sh 함수에 분석기 설정을 추가합니다. 트래비스_설치():

travis_install() {
  wget -q -O - https://files.viva64.com/etc/pubkey.txt 
    | sudo apt-key add -
  sudo wget -O /etc/apt/sources.list.d/viva64.list 
    https://files.viva64.com/etc/viva64.list
  
  sudo apt-get update -qq
  sudo apt-get install -qq pvs-studio 
}

이제 섹션에 추가해 보겠습니다. 스크립트 분석 실행:

script:
  - bash .travis.sh travis_script

그리고 Bash 스크립트에서:

travis_script() {
  pvs-studio-analyzer credentials $PVS_USERNAME $PVS_KEY
  
  if [ "$TRAVIS_PULL_REQUEST" != "false" ]; then
    git diff --name-only origin/HEAD > .pvs-pr.list
    pvs-studio-analyzer analyze -j8 
                                -o PVS-Studio.log 
                                -S .pvs-pr.list 
                                --disableLicenseExpirationCheck
  else
    pvs-studio-analyzer analyze -j8 
                                -o PVS-Studio.log 
                                --disableLicenseExpirationCheck
  fi
  
  plog-converter -t errorfile PVS-Studio.log --cerr -w
}

예를 들어 CMake에서 빌드한 경우 프로젝트를 빌드한 후에 이 코드를 실행해야 합니다.

travis_script() {
  CMAKE_ARGS="-DCMAKE_EXPORT_COMPILE_COMMANDS=On ${CMAKE_ARGS}"
  cmake $CMAKE_ARGS CMakeLists.txt
  make -j8
}

다음과 같이 나타납니다.

travis_script() {
  CMAKE_ARGS="-DCMAKE_EXPORT_COMPILE_COMMANDS=On ${CMAKE_ARGS}"
  cmake $CMAKE_ARGS CMakeLists.txt
  make -j8
  
  pvs-studio-analyzer credentials $PVS_USERNAME $PVS_KEY
  
  if [ "$TRAVIS_PULL_REQUEST" != "false" ]; then
    git diff --name-only origin/HEAD > .pvs-pr.list
    pvs-studio-analyzer analyze -j8 
                                -o PVS-Studio.log 
                                -S .pvs-pr.list 
                                --disableLicenseExpirationCheck
  else
    pvs-studio-analyzer analyze -j8 
                                -o PVS-Studio.log 
                                --disableLicenseExpirationCheck
  fi
  
  plog-converter -t errorfile PVS-Studio.log --cerr -w
}

아마도 이미 이러한 환경 변수를 알아차렸을 것입니다. $TRAVIS_PULL_REQUEST и $TRAVIS_BRANCH. Travis CI는 이를 독립적으로 선언합니다.

• $TRAVIS_PULL_REQUEST 풀 요청 번호를 저장하거나 그릇된, 이것이 일반 지점인 경우;
• $TRAVIS_REPO_SLUG 프로젝트 저장소의 이름을 저장합니다.

이 함수의 알고리즘은 다음과 같습니다.

Travis CI는 반환 코드에 응답하므로 경고가 있으면 서비스가 커밋에 오류가 포함된 것으로 표시하도록 지시합니다.

이제 이 코드 줄을 자세히 살펴보겠습니다.

git diff --name-only origin/HEAD > .pvs-pr.list

사실 Travis CI는 풀 요청을 분석하는 동안 자동으로 브랜치를 병합합니다.

그러므로 우리는 분석한다 A4아니라 B3->A3. 이 기능으로 인해 다음과의 차이를 계산해야 합니다. A3, 이는 정확히 에서 분기의 상단입니다. 출발지.

한 가지 중요한 세부 사항이 남아 있습니다. 컴파일된 번역 단위(*.c, *.cc, *.cpp 등)에 대한 헤더 파일의 종속성을 캐싱하는 것입니다. 분석기는 파일 목록을 확인하는 모드로 처음 실행될 때 이러한 종속성을 계산한 다음 이를 .PVS-Studio 디렉터리에 저장합니다. Travis CI를 사용하면 폴더를 캐시할 수 있으므로 디렉터리 데이터를 저장합니다. .PVS-스튜디오/:

cache:
  directories:
    - .PVS-Studio/

이 코드를 파일에 추가해야 합니다. .travis.yml. 이 디렉터리는 분석 후 수집된 다양한 데이터를 저장하므로 후속 파일 목록 분석 또는 증분 분석 실행 속도가 크게 향상됩니다. 이것이 완료되지 않으면 분석기는 실제로 매번 모든 파일을 분석합니다.

동료

트래비스 CI처럼, 동료 GitHub에 저장된 프로젝트를 자동으로 빌드하고 테스트하는 기능을 제공합니다. Travis CI와 달리 웹 인터페이스에서 구성되므로(bash 지원 가능) 프로젝트에 구성 파일을 저장할 필요가 없습니다.

우선, 조립 라인에 새로운 작업을 추가해야 합니다.

프로젝트를 빌드하는 데 사용된 컴파일러를 지정해 보겠습니다. 이 작업에 설치된 Docker 컨테이너를 확인하세요. 예를 들어, GCC를 위한 특별한 컨테이너가 있습니다:

이제 PVS-Studio와 필요한 유틸리티를 설치해 보겠습니다.

편집기에 다음 줄을 추가해 보겠습니다.

apt-get update && apt-get -y install wget gnupg jq

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

이제 실행 탭(첫 번째 아이콘)으로 이동하여 해당 편집기 필드에 다음 코드를 추가해 보겠습니다.

pvs-studio-analyzer credentials $PVS_USERNAME $PVS_KEY

if [ "$BUDDY_EXECUTION_PULL_REQUEST_NO" != '' ]; then
  PULL_REQUEST_ID="pulls/$BUDDY_EXECUTION_PULL_REQUEST_NO"
  MERGE_BASE=`wget -qO - 
    https://api.github.com/repos/${BUDDY_REPO_SLUG}/${PULL_REQUEST_ID} 
    | jq -r ".base.ref"`

  git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck 
                              -S .pvs-pr.list
else
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck
fi

plog-converter -t errorfile PVS-Studio.log --cerr -w

Travs-CI 섹션을 읽었다면 이 코드는 이미 익숙할 것입니다. 그러나 이제 새로운 단계가 있습니다.

사실 이제 우리는 병합 결과가 아니라 풀 요청이 이루어진 브랜치의 HEAD를 분석합니다.

그래서 우리는 조건부 커밋을 하고 있습니다. B3 그리고 우리는 차이점을 얻어야합니다 A3:

PULL_REQUEST_ID="pulls/$BUDDY_EXECUTION_PULL_REQUEST_NO"
  MERGE_BASE=`wget -qO - 
    https://api.github.com/repos/${BUDDY_REPO_SLUG}/${PULL_REQUEST_ID} 
    | jq -r ".base.ref"`
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list

결정하기 A3 GitHub API를 사용해 보겠습니다.

https://api.github.com/repos/${USERNAME}/${REPO}/pulls/${PULL_REQUEST_ID}

Buddy가 제공하는 다음 변수를 사용했습니다.

• $BUDDY_EXECUTION_PULL_REQEUST_NO — 풀 요청 번호
• $BUDDY_REPO_SLUG — 사용자 이름과 저장소의 조합(예: max/test)

이제 아래 버튼을 사용하여 변경 사항을 저장하고 풀 요청 분석을 활성화하겠습니다.

Travis CI와 달리 지정할 필요가 없습니다. .pvs-스튜디오 캐싱을 위해 Buddy는 후속 실행을 위해 모든 파일을 자동으로 캐시하기 때문입니다. 따라서 마지막으로 PVS-Studio의 로그인과 비밀번호를 Buddy에 저장하는 일만 남았습니다. 변경 사항을 저장한 후 파이프라인으로 돌아갑니다. 변수를 설정하고 PVS-Studio에 대한 로그인 및 키를 추가해야 합니다.

그 후 새로운 풀 요청이나 커밋이 나타나면 검토가 시작됩니다. 커밋에 오류가 있으면 Buddy는 풀 요청 페이지에 이를 표시합니다.

앱베이어

AppVeyor 설정은 모든 것이 웹 인터페이스에서 이루어지고 프로젝트 저장소에 *.yml 파일을 추가할 필요가 없기 때문에 Buddy와 유사합니다.

프로젝트 개요의 설정 탭으로 이동해 보겠습니다.

이 페이지를 아래로 스크롤하여 풀 요청 수집을 위한 캐시 저장을 활성화해 보겠습니다.

이제 어셈블리용 이미지와 필요한 환경 변수를 지정하는 환경 탭으로 이동하겠습니다.

이전 섹션을 읽었다면 다음 두 변수에 대해 매우 잘 알고 있을 것입니다. PVS_KEY и PVS_USERNAME. 그렇지 않은 경우 PVS-Studio 분석기의 라이센스를 확인하는 데 필요함을 알려드립니다. 나중에 Bash 스크립트에서 다시 보게 될 것입니다.

아래 같은 페이지에 캐싱 폴더가 표시되어 있습니다.

이렇게 하지 않으면 몇 개의 파일 대신 전체 프로젝트를 분석하지만 지정된 파일에서 출력을 얻게 됩니다. 따라서 올바른 디렉터리 이름을 입력하는 것이 중요합니다.

이제 스크립트를 테스트할 차례입니다. 테스트 탭을 열고 스크립트를 선택합니다.

이 양식에 다음 코드를 붙여넣어야 합니다.

sudo apt-get update && sudo apt-get -y install jq

wget -q -O - https://files.viva64.com/etc/pubkey.txt 
  | sudo apt-key add -
sudo wget -O /etc/apt/sources.list.d/viva64.list 
  https://files.viva64.com/etc/viva64.list

sudo apt-get update && sudo apt-get -y install pvs-studio

pvs-studio-analyzer credentials $PVS_USERNAME $PVS_KEY

PWD=$(pwd -L)
if [ "$APPVEYOR_PULL_REQUEST_NUMBER" != '' ]; then
  PULL_REQUEST_ID="pulls/$APPVEYOR_PULL_REQUEST_NUMBER"
  MERGE_BASE=`wget -qO - 
    https://api.github.com/repos/${APPVEYOR_REPO_NAME}/${PULL_REQUEST_ID} 
    | jq -r ".base.ref"`

  git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck 
                              --dump-files --dump-log pvs-dump.log 
                              -S .pvs-pr.list
else
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck
fi

plog-converter -t errorfile PVS-Studio.log --cerr -w

코드의 다음 부분에 주목해 보겠습니다.

PWD=$(pwd -L)
if [ "$APPVEYOR_PULL_REQUEST_NUMBER" != '' ]; then
  PULL_REQUEST_ID="pulls/$APPVEYOR_PULL_REQUEST_NUMBER"
  MERGE_BASE=`wget -qO - 
   https://api.github.com/repos/${APPVEYOR_REPO_NAME}/${PULL_REQUEST_ID} 
   | jq -r ".base.ref"`

  git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck 
                              --dump-files --dump-log pvs-dump.log 
                              -S .pvs-pr.list
else
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck
fi

이 기본값을 저장해야 하는 변수에 pwd 명령 값을 특정하게 할당하는 것은 언뜻 보기에는 이상해 보이지만 이제 모든 것을 설명하겠습니다.

AppVeyor에서 분석기를 설정하는 동안 분석기의 매우 이상한 동작을 발견했습니다. 한편으로는 모든 것이 올바르게 작동했지만 분석이 시작되지 않았습니다. 나는 우리가 /home/appveyor/projects/testcalc/ 디렉터리에 있다는 것을 확인하는 데 많은 시간을 보냈고 분석기는 우리가 /opt/appveyor/build-agent/에 있다고 확신합니다. 그러다가 $PWD 변수가 약간 거짓말을 하고 있다는 것을 깨달았습니다. 이러한 이유로 분석을 시작하기 전에 해당 값을 수동으로 업데이트했습니다.

그러면 모든 것이 이전과 같습니다.

이제 다음 부분을 고려해보세요.

PULL_REQUEST_ID="pulls/$APPVEYOR_PULL_REQUEST_NUMBER"
MERGE_BASE=`wget -qO - 
  https://api.github.com/repos/${APPVEYOR_REPO_NAME}/${PULL_REQUEST_ID} 
  | jq -r ".base.ref"`

여기에서 풀 요청이 선언된 브랜치 간의 차이점을 알 수 있습니다. 이를 위해서는 다음과 같은 환경 변수가 필요합니다.

• $APPVEYOR_PULL_REQUEST_NUMBER — 풀 요청 번호;
• $APPVEYOR_REPO_NAME - 사용자 이름 및 프로젝트 저장소.

결론

물론 우리는 가능한 모든 지속적 통합 서비스를 고려하지는 않았지만, 이들 서비스는 모두 서로 매우 유사한 운영 특성을 가지고 있습니다. 캐싱을 제외하고 각 서비스는 자체 "자전거"를 만들기 때문에 모든 것이 항상 다릅니다.

Travis-CI와 같은 곳에서는 몇 줄의 코드와 캐싱이 완벽하게 작동합니다. AppVeyor와 같은 곳에서는 설정에서 폴더를 지정하기만 하면 됩니다. 하지만 어딘가에서 고유한 키를 생성하고 캐시된 조각을 덮어쓸 수 있는 기회를 제공하도록 시스템을 설득해야 합니다. 따라서 위에서 논의되지 않은 지속적인 통합 서비스에 대한 풀 요청 분석을 설정하려면 먼저 캐싱에 문제가 없는지 확인하십시오.

관심을 가져주셔서 감사합니다. 문제가 해결되지 않으면 언제든지 다음 주소로 문의해 주세요. 지지. 조언하고 도와드리겠습니다.

이 기사를 영어권 청중과 공유하려면 번역 링크인 Maxim Zvyagintsev를 사용하십시오. PVS-Studio를 사용하여 Travis CI, Buddy 및 AppVeyor의 커밋 및 풀 요청 분석.

출처 : habr.com