🥇PVS-Studio for C# kullanılarak GitLab'da birleştirme isteklerinin analizi

GitLab'ı seviyor ve böceklerden nefret mi ediyorsunuz? Kaynak kodunuzun kalitesini artırmak mı istiyorsunuz? O halde doğru yere geldiniz. Bugün size PVS-Studio C# analizörünü birleştirme isteklerini kontrol edecek şekilde nasıl yapılandıracağınızı anlatacağız. Herkese tek boynuzlu at havası ve keyifli okumalar dilerim.

PVS-Stüdyo C, C++, C# ve Java ile yazılmış programların kaynak kodundaki hataları ve olası güvenlik açıklarını belirlemeye yönelik bir araçtır. Windows, Linux ve macOS'ta 64 bit sistemlerde çalışır. 32 bit, 64 bit ve gömülü ARM platformları için tasarlanmış kodları analiz edebilir.

Bu arada, birçok şey yaptığımız PVS-Studio 7.08'i piyasaya sürdük. ilginç. Örneğin:

Linux ve macOS için C# analizörü;
Rider için eklenti;
yeni dosya listesi kontrol modu.

Dosya listesi kontrol modu

Önceden, belirli dosyaları kontrol etmek için analizöre dosya listesini içeren bir .xml dosyasının iletilmesi gerekiyordu. Ancak bu pek kullanışlı olmadığından hayatı çok kolaylaştıran .txt aktarma özelliğini ekledik.

Belirli dosyaları kontrol etmek için bayrağı belirtmelisiniz --kaynak dosyaları (-f) ve .txt dosyasını bir dosya listesiyle birlikte aktarın. Şuna benziyor:

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

Taahhüt kontrolü veya çekme istekleri ayarlamakla ilgileniyorsanız, bunu bu modu kullanarak da yapabilirsiniz. Aradaki fark, analiz edilecek dosyaların bir listesinin alınmasında olacak ve hangi sistemleri kullandığınıza bağlı olacaktır.

Birleştirme isteğini kontrol etme ilkesi

Kontrolün temel özü, analizör tarafından birleştirme sırasında tespit edilen sorunların, usta dal. Ayrıca her seferinde projenin tamamını analiz etmek istemiyoruz. Üstelik şubeleri birleştirirken değişen dosyaların bir listesine sahibiz. Bu nedenle birleştirme isteği kontrolü eklemenizi öneririm.

Statik analizör uygulamadan önce birleştirme isteği şu şekilde görünür:

Yani, daldaki tüm hatalar değişiklikler, ana şubeye taşınacak. Bunu istemeyeceğimiz için analiz ekliyoruz ve artık diyagram şu şekilde görünüyor:

Analiz değişiklikler2 ve herhangi bir hata yoksa birleştirme isteğini kabul ederiz, aksi takdirde reddederiz.

Bu arada, C/C++ için taahhütleri ve çekme isteklerini analiz etmekle ilgileniyorsanız, bunu okuyabilirsiniz. burada.

GitLab

GitLab Git için kendi wiki'si, sorun izleme sistemi, CI/CD hattı ve diğer özellikleriyle bir kod deposu yönetim sistemi sağlayan açık kaynaklı, web tabanlı bir DevOps yaşam döngüsü aracıdır.

Birleştirme isteklerini analiz etmeye başlamadan önce projenizi kaydetmeniz ve yüklemeniz gerekir. Bunu nasıl yapacağınızı bilmiyorsanız, öneririm Makale meslektaşım.

Dikkat. Aşağıda açıklanan ortamı kurma yöntemi olası yöntemlerden biridir. Amaç, analiz için gerekli ortamın kurulması ve analizörün başlatılmasına yönelik adımları göstermektir. Belki de sizin durumunuzda, ortam hazırlama (depo ekleme, analizör kurma) ve analiz aşamalarını ayırmak daha uygun olacaktır: örneğin, Docker görüntülerini gerekli ortamla hazırlamak ve bunları kullanmak veya başka bir yöntemle.

Şimdi ne olacağını daha iyi anlamak için aşağıdaki şemaya bakmanızı öneririm:

Analizörün çalışması için .NET Core SDK 3 gerekir, bu nedenle analizörü kurmadan önce analizör için gerekli bağımlılıkların kurulacağı Microsoft depolarını eklemeniz gerekir. Çeşitli Linux dağıtımları için Microsoft depoları ekleme ilgili belgede açıklanmıştır.

PVS-Studio'yu paket yöneticisi aracılığıyla kurmak için PVS-Studio depolarını da eklemeniz gerekecektir. Farklı dağıtımlar için depoların eklenmesi bölümünde daha ayrıntılı olarak açıklanmaktadır. belgelerin ilgili bölümü.

Analizörün çalışması için bir lisans anahtarı gerekir. Deneme lisansını şu adresten alabilirsiniz: analizör indirme sayfası.

Dikkat. Açıklanan çalışma modunun (birleştirme isteklerinin analizi) bir Kurumsal lisans gerektirdiğini lütfen unutmayın. Bu nedenle bu çalışma modunu denemek istiyorsanız “Mesaj” alanına Enterprise lisansına ihtiyacınız olduğunu belirtmeyi unutmayın.

Bir birleştirme isteği oluşursa, yalnızca değiştirilen dosyaların listesini analiz etmemiz gerekir, aksi takdirde tüm dosyaları analiz ederiz. Analiz sonrasında logları ihtiyacımız olan formata dönüştürmemiz gerekiyor.

Artık işin algoritmasını gözlerinizin önünde tutarak bir senaryo yazmaya geçebilirsiniz. Bunu yapmak için dosyayı değiştirmeniz gerekir .gitlab-ci.yml veya mevcut değilse oluşturun. Bunu oluşturmak için projenizin adına tıklamanız gerekir -> CI/CD'yi kurma.

Artık senaryoyu yazmaya hazırız. Öncelikle analizörün kurulumunu yapacak kodu yazıp lisansı girelim:

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

Kurulum ve etkinleştirmenin diğer tüm komut dosyalarından önce gerçekleşmesi gerektiğinden özel bir etiket kullanıyoruz önce_script. Bu parçayı biraz açıklayayım.

Analizörü kurmaya hazırlanıyor:

  - 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 depoları ve analizörünü ekleme:

  - 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

Lisans aktivasyonu:

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$PVS_NAME - Kullanıcı adı.

$PVS_KEY - ürün anahtarı.

Proje bağımlılıklarının kurtarılması $CI_PROJECT_DIR – proje dizininin tam yolu:

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

Doğru analiz için projenin başarıyla derlenmesi ve bağımlılıklarının geri yüklenmesi gerekir (örneğin, gerekli NuGet paketlerinin indirilmesi gerekir).

Lisans bilgilerini içeren ortam değişkenlerini tıklatarak ayarlayabilirsiniz. ayarve sonrasında - açık CI/CD.

Açılan pencerede öğeyi bulun Değişkenler, sağdaki düğmeye tıklayın Genişletmek ve değişkenleri ekleyin. Sonuç şu şekilde görünmelidir:

Artık analize geçebilirsiniz. Öncelikle tam bir analiz için bir komut dosyası ekleyelim. Bayrağa -t çözüme giden yolu bayrağa geçiriyoruz -o Analiz sonuçlarının yazılacağı dosyanın yolunu yazın. Ayrıca dönüş koduyla da ilgileniyoruz. Bu durumda, dönüş kodu analiz sırasında uyarı verildiğine dair bilgi içerdiğinde işlemin durdurulmasıyla ilgileniyoruz. Bu fragman şöyle görünüyor:

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

Dönüş kodları bit maskesi prensibiyle çalışır. Örneğin analiz sonucunda uyarı verilmişse dönüş kodu 8 olacaktır. Lisansın süresi bir ay içinde dolarsa dönüş kodu 4 olacaktır. Analiz sırasında hata tespit edilmişse, ve lisansın süresi bir ay içinde doluyor, kod dönüşü, her iki değer de yazılacak: sayıları toplayın ve son dönüş kodunu alın - 8+4=12. Böylece karşılık gelen bitlerin kontrol edilmesiyle analiz sırasında çeşitli durumlar hakkında bilgi elde edilebilir. Dönüş kodları, belgenin "pvs-studio-dotnet (Linux / macOS) Dönüş Kodları" bölümünde daha ayrıntılı olarak açıklanmaktadır "PVS-Studio kullanarak Visual Studio / MSBuild / .NET Core projelerini komut satırından kontrol etme".

Bu durumda 8'in göründüğü tüm dönüş kodlarıyla ilgileniyoruz.

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

Dönüş kodu ilgilendiğimiz sayının bitini içerdiğinde 1 alacağız, aksi takdirde 0 alacağız.

Birleştirme isteği analizini eklemenin zamanı geldi. Bunu yapmadan önce senaryo için bir yer hazırlayalım. Yalnızca bir birleştirme isteği oluştuğunda yürütülmesine ihtiyacımız var. Şuna benziyor:

merge:
  script:
  only:
  - merge_requests

Senaryonun kendisine geçelim. Sanal makinenin hakkında hiçbir şey bilmediği gerçeğiyle karşı karşıya kaldım köken/usta. O halde ona biraz yardım edelim:

  - git fetch origin

Şimdi dallar arasındaki farkı alıp sonucu kaydediyoruz. txt dosya:

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

Nerede $CI_COMMIT_SHA – son işlemin karması.

Daha sonra bayrağı kullanarak dosya listesini analiz etmeye başlıyoruz -f. Daha önce aldığımız .txt dosyasını ona aktarıyoruz. Tam analize benzeterek dönüş kodlarına bakıyoruz:

  - 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

Birleştirme isteğini kontrol etmeye yönelik komut dosyasının tamamı şöyle görünecektir:

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

Geriye kalan tek şey, tüm komut dosyaları işlendikten sonra günlük dönüşümünü eklemektir. Etiketi kullanıyoruz after_script ve fayda plog-dönüştürücü:

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

Yarar plog-dönüştürücü ayrıştırıcı hata raporlarını HTML gibi çeşitli formlara dönüştürmek için kullanılan açık kaynaklı bir projedir. Yardımcı programın daha ayrıntılı bir açıklaması "Plog Dönüştürücü Yardımcı Programı" alt bölümünde verilmiştir. belgelerin ilgili bölümü.

Bu arada, IDE'den yerel olarak .json raporlarıyla rahatça çalışmak istiyorsanız, o zaman şunu öneririm: Eklentisi IDE Rider için. Kullanımı şurada daha ayrıntılı olarak anlatılmıştır. Ilgili belge.

Kolaylık sağlamak için, işte burada .gitlab-ci.yml dolu:

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

Her şeyi dosyaya ekledikten sonra, üzerine tıklayın. Değişiklikleri taahhüt et. Her şeyin doğru olduğunu görmek için şuraya gidin: CI / CD -> Boru Hatları -> Koşu. Sonunda aşağıdakilerin olması gereken bir sanal makine penceresi açılacaktır:

Testere İş başarılı oldu - başarı, her şey yolunda. Artık ne yaptığınızı test edebilirsiniz.

Çalışma örnekleri

Bir çalışma örneği için basit bir proje oluşturalım (içinde usta) birkaç dosya içerecektir. Bundan sonra başka bir dalda sadece bir dosyayı değiştirip birleştirme isteğinde bulunmaya çalışacağız.

İki durumu ele alalım: değiştirilen dosyada bir hata olduğunda ve olmadığında. İlk olarak hatalı bir örnek.

Diyelim ki ana dalda bir dosya var Program.cshata içermeyen ancak başka bir dalda geliştirici hatalı kod eklemiş ve birleştirme isteği yapmak istiyor. Ne tür bir hata yaptığı o kadar önemli değil, asıl mesele onun var olmasıdır. Örneğin operatör unuttu atmak (Evet, çok yanlış):

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

Hatalı bir örneği analiz etmenin sonucuna bakalım. Ayrıca yalnızca bir dosyanın ayrıştırıldığından emin olmak için bayrağı ekledim -r pvs-studio-dotnet başlatma satırına:

Analizörün bir hata bulduğunu ve dalların birleştirilmesine izin vermediğini görüyoruz.

Örneği hatasız olarak kontrol edelim. Kodun düzeltilmesi:

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

İstek analizi sonuçlarını birleştirme:

Gördüğümüz gibi hiçbir hata bulunamadı ve görevin yürütülmesi başarılı oldu, biz de bunu kontrol etmek istedik.

Sonuç

Dalları birleştirmeden önce kötü kodları ayıklamak çok kullanışlı ve keyiflidir. Dolayısıyla, CI/CD kullanıyorsanız kontrol etmek için bir statik analizör yerleştirmeyi deneyin. Üstelik bu oldukça basit bir şekilde yapılıyor.

İlginiz için teşekkür ederiz.

Bu makaleyi İngilizce konuşan bir kitleyle paylaşmak istiyorsanız lütfen çeviri bağlantısını kullanın: Nikolay Mironov. C# için PVS-Studio kullanılarak GitLab'daki birleştirme isteklerinin analizi.

Kaynak: habr.com