Mulai dari versi 7.04, penganalisa PVS-Studio untuk bahasa C dan C ++ di Linux dan macOS menyediakan fitur uji untuk memeriksa daftar file yang ditentukan. Dengan menggunakan mode baru, Anda dapat mengonfigurasikan penganalisis untuk memeriksa komit dan menarik permintaan. Artikel ini mencakup pengaturan pemeriksaan file modifikasi tertentu dari proyek GitHub dalam sistem CI (Continuous Integration) yang populer, seperti Travis CI, Buddy, dan AppVeyor.
Mode memeriksa daftar file
PVS-Studio adalah alat yang dirancang untuk mendeteksi kesalahan dan kerentanan potensial dalam kode sumber program, ditulis dalam C, C ++, C # dan Java. Bekerja di sistem 64-bit pada Windows, Linux dan macOS.
Dalam versi PVS-Studio 7.04 untuk Linux dan macOS sekarang ada mode memeriksa daftar file. Ini berfungsi untuk proyek-proyek, yang sistem pembangunannya memungkinkan menghasilkan file
compile_commands.json . Diperlukan agar penganalisa untuk mendapatkan informasi tentang kompilasi file tertentu. Jika sistem build Anda tidak mendukung pembuatan file compile_commands.json, Anda dapat mencoba membuat file seperti itu menggunakan utilitas
Bear .
Mode ini memeriksa daftar file juga dapat digunakan dengan compiler run tracing log yang dihasilkan oleh strace (pvs-studio-analyzer trace). Untuk melakukannya, pertama-tama Anda harus menyelesaikan pembangunan proyek penuh dan lacak sehingga penganalisa mengumpulkan informasi lengkap tentang parameter kompilasi semua file yang diperiksa.
Namun, opsi ini memiliki kelemahan yang signifikan - Anda harus melakukan penelusuran build penuh dari seluruh proyek dengan setiap proses, yang bertentangan dengan gagasan pengecekan komit cepat. Atau jika Anda menyimpan hasil penelusuran itu sendiri, proses analisis selanjutnya mungkin tidak lengkap jika seandainya setelah melacak struktur perubahan dependensi file sumber (misalnya, #include baru ditambahkan di salah satu file sumber).
Oleh karena itu, kami tidak menyarankan menggunakan mode memeriksa daftar file dengan tracing log untuk memeriksa komit atau menarik permintaan. Jika Anda bisa melakukan pengembangan bertahap saat memeriksa komit, pertimbangkan untuk menggunakan mode
analisis tambahan .
Daftar file sumber untuk analisis disimpan dalam file teks dan diteruskan ke penganalisis menggunakan parameter
-S :
pvs-studio-analyzer analyze ... -f build/compile_commands.json -S check-list.txt
File ini berisi path relatif dan absolut ke file di mana setiap file baru datang pada baris baru. Anda dapat menentukan nama file untuk analisis dan teks yang berbeda. Sedangkan untuk teks, penganalisa akan melihat bahwa itu bukan nama file dan akan mengabaikan baris. Mungkin bermanfaat untuk berkomentar jika file ditentukan secara manual. Namun, seringkali daftar file akan dihasilkan selama analisis CI, misalnya, dapat berupa file dari komit atau permintaan tarik.
Sekarang menggunakan mode ini Anda dapat dengan cepat memeriksa kode baru sebelum masuk ke cabang pengembangan utama.
Bendera --indicate-warnings telah ditambahkan di utilitas
plog-converter sehingga sistem pemeriksaan merespons keberadaan peringatan penganalisa.
plog-converter ... --indicate-warnings ... -o /path/to/report.tasks ...
Dengan tanda ini, konverter akan mengembalikan kode bukan nol jika ada peringatan dalam laporan analisa. Anda dapat memblokir hook pra-komit, melakukan atau menarik permintaan dan menampilkan laporan analisa yang dihasilkan, membagikan atau mengirimkannya melalui pos.
Catatan Selama analisis pertama dari daftar file, seluruh proyek akan diperiksa, karena penganalisa harus menghasilkan file dengan dependensi file sumber proyek dari file header. Ini adalah kekhasan analisis file C dan C ++. Di masa depan, file dependensi ini dapat di-cache dan akan diperbarui secara otomatis oleh penganalisa. Keuntungan memeriksa komit menggunakan mode memeriksa daftar file di atas mode analisis tambahan adalah fakta bahwa Anda harus melakukan cache hanya file ini, bukan file objek.Prinsip umum analisis permintaan tarik
Keseluruhan analisis proyek membutuhkan banyak waktu, jadi masuk akal untuk memeriksa hanya sebagian saja. Masalahnya adalah Anda harus memisahkan file baru dari sisa file proyek.
Mari kita lihat contoh pohon komit dua cabang:
Bayangkan komit
A1 berisi kode dalam jumlah cukup besar yang sudah diperiksa. Sebelumnya, kami telah membuat cabang dari komit
A1 dan mengubah beberapa file.
Tentu saja, Anda telah memperhatikan bahwa setelah
A1 dua komit lainnya terjadi, dan dua cabang lainnya bergabung, karena kami tidak berkomitmen pada
master . Inilah saatnya ketika
perbaikan terbaru siap. Itu sebabnya kami mendapat permintaan tarik untuk penggabungan
B3 dan
A3 .
Kami dapat memeriksa hasil penggabungan mereka, tetapi akan terlalu lama dan tidak masuk akal, karena hanya beberapa file yang telah dimodifikasi. Oleh karena itu, lebih efisien untuk menganalisis hanya yang berubah.
Untuk melakukannya, kami akan menerima perbedaan antara cabang, berada di KEPALA cabang, dari mana kami ingin bergabung menjadi master:
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list
Kami akan mempertimbangkan
$ MERGE_BASE secara detail nanti. Faktanya adalah bahwa tidak setiap layanan CI menyediakan informasi yang diperlukan di pangkalan gabungan, jadi setiap kali kita harus memikirkan cara-cara baru untuk mendapatkan data ini. Ini akan dipertimbangkan secara terperinci di bawah ini untuk masing-masing layanan web yang dijelaskan.
Jadi kami mendapat perbedaan antara cabang, yang merupakan daftar nama file yang dimodifikasi. Sekarang kita perlu memberi makan file
.pvs-pr.list ini ke penganalisa. Kami telah mengarahkan ulang output ke sana sebelumnya.
pvs-studio-analyzer analyze -j8 \ -o PVS-Studio.log \ -S .pvs-pr.list
Setelah analisis, kita perlu mengkonversi file log (PVS-Studio.log) menjadi format yang mudah digunakan:
plog-converter -t errorfile PVS-Studio.log --cerr -w
Perintah ini akan menampilkan daftar kesalahan dalam
stderr (aliran kesalahan standar).
Tangkapannya adalah kita tidak hanya perlu menampilkan kesalahan, tetapi juga melaporkan layanan build dan test kami tentang masalah tersebut. Untuk melakukan ini,
flag -W (
--indicate-warning ) telah ditambahkan di konverter. Jika setidaknya ada satu penganalisa peringatan, kode pengembalian utilitas
plog-converter akan berubah menjadi 2, yang pada gilirannya akan melaporkan layanan CI tentang potensi kesalahan dalam file permintaan tarik.
Travis ci
Konfigurasi dibuat dalam bentuk file
.travis.yml . Untuk kenyamanan, saya menyarankan Anda untuk mengisolasi semua perintah yang terkait dengan PVS-Studio dalam skrip bash terpisah dengan fungsi yang akan dipanggil dari file
.travis.yml (
bash script_name.sh function_name ).
Dengan memperluas skrip, Anda akan mendapatkan lebih banyak fungsi. Di bagian
instal, tulis yang berikut ini:
install: - bash .travis.sh travis_install
Jika Anda memiliki beberapa instruksi, Anda dapat memindahkannya dalam skrip, setelah menghapus tanda hubung.
Buka file
.travis.sh dan tambahkan instalasi analyzer di fungsi
travis_install () :
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 }
Sekarang mari kita tambahkan penganalisis yang dijalankan di bagian
skrip :
script: - bash .travis.sh travis_script
Dan dalam skrip 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 }
Anda harus menjalankan kode ini setelah membangun proyek, misalnya, jika Anda memiliki build di CMake:
travis_script() { CMAKE_ARGS="-DCMAKE_EXPORT_COMPILE_COMMANDS=On ${CMAKE_ARGS}" cmake $CMAKE_ARGS CMakeLists.txt make -j8 }
Anda akan mendapatkan yang berikut ini:
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 }
Kemungkinan besar, Anda sudah memperhatikan variabel lingkungan
$ TRAVIS_PULL_REQUEST dan
$ TRAVIS_BRANCH . Travis CI menyatakannya sendiri:
- $ TRAVIS_PULL_REQUEST menyimpan nomor permintaan tarik atau salah jika itu cabang biasa;
- $ TRAVIS_REPO_SLUG menyimpan nama repositori proyek.
Berikut algoritma operasional dari fungsi ini:
Travis CI merespons kode kembali, sehingga keberadaan peringatan akan melaporkan layanan untuk menandai komit sebagai berisi kesalahan.
Sekarang mari kita lihat lebih dekat pada baris kode ini:
git diff --name-only origin/HEAD > .pvs-pr.list
Faktanya adalah bahwa Travis CI secara otomatis menggabungkan cabang ketika menganalisis permintaan tarik:
Itu sebabnya kami menganalisis
A4 , bukan
B3-> A3 . Karena kekhasan ini, kita perlu mengevaluasi perbedaannya dengan
A3 , yang merupakan kepala cabang dari
asal .
Satu detail penting tetap - caching dependensi file header dari unit terjemahan yang dikompilasi (* .c, * .cc, * .cpp dan lainnya). Penganalisis mengevaluasi dependensi ini selama menjalankan pertama dalam mode memeriksa daftar file dan kemudian menyimpannya dalam direktori .PVS-Studio. Travis CI memungkinkan repositori caching, jadi kami akan menyimpan data di
direktori .PVS-Studio / :
cache: directories: - .PVS-Studio/
Kode ini harus ditambahkan dalam file
.travis.yml : Direktori ini menyimpan berbagai data, dikumpulkan setelah analisis. Data ini secara signifikan mempercepat proses selanjutnya dari analisis daftar file atau analisis tambahan. Jika Anda tidak melakukannya, penganalisa akan menganalisis semua file setiap saat.
Sobat
Sama seperti Travis CI,
Buddy memungkinkan Anda membangun dan menguji proyek dari GitHub secara otomatis. Tidak seperti Travis CI, ini dikonfigurasi dalam antarmuka web (dukungan bash tersedia), sehingga tidak perlu menyimpan file konfigurasi dalam proyek.
Pertama, kita perlu menambahkan langkah baru ke dalam pipa:
Mari kita tentukan kompiler yang digunakan untuk membangun proyek. Perhatikan wadah buruh pelabuhan, dipasang pada langkah ini. Misalnya, ada wadah khusus untuk GCC:
Sekarang mari kita instal PVS-Studio dan utilitas yang diperlukan:
Tambahkan baris berikut ke editor:
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
Mari beralih ke tab Jalankan (ikon pertama) dan tambahkan kode berikut ke bidang editor yang sesuai:
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
Jika Anda membaca bagian tentang Travs-CI, kode ini tidak asing bagi Anda. Tapi di sini ada langkah baru:
Faktanya adalah bahwa sekarang kami menganalisis bukan hasil penggabungan, tetapi KEPALA cabang dengan permintaan tarik dicentang:
Jadi kita berada dalam komit
B3 dan kita perlu mendapatkan perbedaan dengan
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
Untuk mendefinisikan
A3 mari kita gunakan API GitHub:
https://api.github.com/repos/${USERNAME}/${REPO}/pulls/${PULL_REQUEST_ID}
Kami menggunakan variabel-variabel berikut, yang disediakan oleh Sobat:
- $ BUDDY_EXECUTION_PULL_REQEUST_NO - jumlah permintaan tarik;
- $ BUDDY_REPO_SLUG - kombinasi nama pengguna dan repositori (misalnya, maks / uji).
Sekarang mari kita simpan perubahan, menggunakan tombol di bawah ini dan aktifkan analisis permintaan tarik:
Tidak seperti Travis CI, kami tidak perlu menentukan
.pvs-studio untuk caching, karena Buddy secara otomatis menyimpan semua file untuk proses selanjutnya. Jadi hal terakhir yang tersisa adalah menyimpan login dan kata sandi untuk PVS-Studio di Buddy. Setelah menyimpan perubahan, kami akan kembali ke Pipeline. Kita perlu beralih ke pengaturan variabel dan masukkan login dan kunci untuk PVS-Studio:
Setelah ini, cek akan dimulai dengan setiap permintaan tarik baru atau komit. Jika komit berisi kesalahan, Buddy akan menunjukkannya di halaman permintaan tarik.
Pengantar
Pengaturan AppVeyor mirip dengan Sobat, karena semuanya terjadi di antarmuka web dan tidak perlu menambahkan file * .yml di repositori proyek.
Mari kita pergi ke tab Pengaturan di ulasan proyek:
Gulir halaman ini ke bawah dan aktifkan penyimpanan cache untuk pembuatan permintaan tarik:
Sekarang mari kita beralih ke tab Lingkungan, di mana kita akan menentukan gambar untuk variabel lingkungan yang diperlukan dan dibangun:
Jika Anda sudah membaca bagian sebelumnya, Anda sudah terbiasa dengan dua variabel ini -
PVS_KEY dan
PVS_USERNAME . Jika tidak, izinkan saya mengingatkan Anda bahwa mereka diperlukan untuk memeriksa lisensi penganalisa PVS-Studio. Di masa depan, kita akan bertemu mereka lagi dalam skrip Bash.
Pada halaman yang sama di bagian bawah, mari kita tentukan folder cache:
Jika kami tidak melakukannya, kami akan menganalisis seluruh proyek alih-alih beberapa file, tetapi akan menerima output untuk file yang ditentukan. Jadi, penting untuk memasukkan nama repositori yang benar.
Sekarang waktunya telah tiba untuk naskah pemeriksaan. Buka tab Tes dan pilih Script:
Kode berikut harus dimasukkan ke dalam formulir ini:
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
Mari kita perhatikan bagian kode berikut:
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
Ini adalah tugas yang cukup spesifik dari nilai output perintah pwd ke variabel, yang harus menyimpan nilai ini secara default. Awalnya tampak aneh, tapi izinkan saya menjelaskan semuanya.
Saat menyiapkan penganalisis di AppVeyor, saya menemukan perilaku penganalisa yang sangat aneh. Di satu sisi, semuanya bekerja dengan benar, tetapi analisisnya tidak dimulai. Butuh banyak waktu untuk memperhatikan bahwa kami berada di direktori / home / appveyor / proyek / testcalc /, sedangkan analis yakin bahwa kami berada di / opt / appveyor / build-agent /. Pada saat itu saya menyadari bahwa variabel $ PWD adalah tipu. Untuk alasan ini, saya secara manual memperbarui nilainya sebelum menjalankan analisis.
Urutan tindakan selanjutnya sama dengan sebelumnya:
Sekarang lihat fragmen ini:
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"`
Di dalamnya kita mendapatkan perbedaan antara cabang, terkait dengan permintaan tarik dicentang. Untuk melakukan ini, kita memerlukan variabel lingkungan berikut:
- $ APPVEYOR_PULL_REQUEST_NUMBER - tarik nomor permintaan;
- $ APPVEYOR_REPO_NAME - nama pengguna dan repositori proyek.
Kesimpulan
Yah, kami belum mempertimbangkan semua layanan integrasi berkesinambungan yang mungkin, namun, mereka semua memiliki spesifikasi operasional yang serupa. Tetapi untuk caching, setiap layanan menemukan kembali rodanya sendiri, sehingga selalu berbeda.
Dalam beberapa kasus (seperti dalam Travis-CI) dibutuhkan beberapa baris kode - dan caching berfungsi dengan sempurna. Dalam kasus lain (seperti pada AppVeyor), Anda hanya perlu menentukan direktori dalam pengaturan. Tetapi ada beberapa layanan, di mana Anda perlu membuat kunci khusus dan mencoba meyakinkan sistem untuk memberi Anda kesempatan untuk menulis ulang fragmen yang di-cache. Karenanya, jika Anda ingin mengonfigurasi analisis permintaan tarik pada layanan integrasi berkelanjutan, yang tidak dipertimbangkan di atas, pertama-tama, pastikan Anda tidak akan mengalami masalah dengan caching.
Terima kasih atas perhatian anda Jika sesuatu tidak berhasil, Anda dapat dengan aman menulis surat kepada
dukungan kami. Kami akan memberi Anda petunjuk dan bantuan.