ci_helloworld
1.0.0
การซื้อคืนนี้ให้ตัวอย่างง่ายๆ สำหรับวิธีตั้งค่าบริการ CI ต่างๆ ตลอดจนการรวมเครื่องมือการวิเคราะห์เข้ากับบริการเหล่านี้ เครื่องมือเหล่านี้ควรใช้เป็นส่วนหนึ่งของกระบวนการพัฒนาซอฟต์แวร์ (SDP) ที่ครอบคลุม และยังสามารถใช้เป็นเทมเพลตเริ่มต้นสำหรับแอปพลิเคชัน C หรือ C++ ใดๆ ก็ได้ ใช้เครื่องมือ CI ต่อไปนี้ ซึ่งให้การสนับสนุนการทดสอบสำหรับ Windows, Cygwin, Linux และ macOS
มีการดำเนินการตรวจสอบต่อไปนี้:
โครงการในโลกแห่งความเป็นจริงต่อไปนี้ใช้เทคนิคที่หลากหลายเหล่านี้เป็นส่วนหนึ่งของ SDP:
แม้ว่า repo นี้สามารถทำให้ทำงานบนระบบส่วนใหญ่ได้ แต่แพลตฟอร์มที่รองรับและการขึ้นต่อกันมีดังต่อไปนี้:
sudo apt-get install git build-essential cmake
setup-x86_64.exe -q -P git,make,gcc-core,gcc-g++,cmake
ติดตั้งแพ็คเกจต่อไปนี้:
เพื่อคอมไพล์และติดตั้งตัวอย่างนี้ ให้ใช้คำแนะนำต่อไปนี้:
git clone https://github.com/ainfosec/ci_helloworld.git
mkdir ci_helloworld/build
cd ci_helloworld/build
cmake ..
make
make test
git clone https://github.com/ainfosec/ci_helloworld.git
mkdir ci_helloworld/build
cd ci_helloworld/build
cmake -G "NMake Makefiles" ..
nmake
nmake test
git clone https://github.com/ainfosec/ci_helloworld.git
mkdir ci_helloworld/build
cd ci_helloworld/build
cmake -G "Visual Studio 15 2017 Win64" ..
msbuild ci_helloworld.sln
ctest
git clone https://github.com/ainfosec/ci_helloworld.git
mkdir ci_helloworld/build
cd ci_helloworld/build
cmake ..
make
make test
ข้อมูลต่อไปนี้ให้คำอธิบายของเครื่องมือวิเคราะห์ทั้งหมดที่รวมอยู่ในบริการ CI ที่ใช้โดยโปรเจ็กต์นี้ รวมถึงคำอธิบายวิธีการทำงาน
CI ได้รับการตั้งค่าเพื่อตรวจสอบเอกสารที่หายไปโดยใช้ doxygen ไม่เหมือนกับเครื่องมือวิเคราะห์ส่วนใหญ่ที่ใช้ในโปรเจ็กต์นี้ ไม่มีเป้าหมายสำหรับ doxygen แต่กลับรันโดยใช้ doxygen ด้วยตนเองด้วยสคริปต์ต่อไปนี้:
- doxygen .doxygen.txt
- |
if [[ -s doxygen_warnings.txt ]]; then
echo "You must fix doxygen before submitting a pull request"
echo ""
cat doxygen_warnings.txt
exit -1
fi สคริปต์นี้รัน doxygen กับซอร์สโค้ดและคำเตือนใดๆ จะถูกวางไว้ในไฟล์ชื่อ doxygen_warnings.txt หากไฟล์นี้ว่างเปล่า หมายความว่าการวิเคราะห์ doxygen ผ่าน และโค้ดทั้งหมดได้รับการบันทึกไว้ตามการตั้งค่าในไฟล์การกำหนดค่า .doxygen.txt หากไฟล์นี้ไม่ว่างเปล่า การทดสอบจะล้มเหลว และพิมพ์คำเตือนที่สร้างโดย doxygen
git diff --check มอบวิธีง่ายๆ ในการตรวจจับเมื่อมีการตรวจสอบข้อผิดพลาดช่องว่างใน repo รวมถึงการตรวจสอบว่าเมื่อใดการขึ้นบรรทัดใหม่ของไฟล์หายไปหรือมีมากเกินไป ข้อมูลเพิ่มเติมเกี่ยวกับเช็คนี้สามารถพบได้ที่นี่ การตรวจสอบนี้มีประโยชน์อย่างยิ่งสำหรับนักพัฒนาเมื่อ PR มีการแก้ไขที่ไม่เกี่ยวข้องกับการเปลี่ยนแปลงเฉพาะของพวกเขา
- |
if [[ -n $(git diff --check HEAD^) ]]; then
echo "You must remove whitespace before submitting a pull request"
echo ""
git diff --check HEAD^
exit -1
fi การตรวจสอบนี้จะรัน git diff --check ซึ่งจะส่งคืนพร้อมข้อผิดพลาดหากการตรวจสอบล้มเหลว หากเกิดเหตุการณ์นี้ ส่วนต่างจะปรากฏขึ้นให้ผู้ใช้เห็น
การจัดรูปแบบซอร์สโค้ดเป็นวิธีที่ดีเยี่ยมในการรักษารูปลักษณ์ของโค้ดให้สอดคล้องกัน ปัญหาเกี่ยวกับการจัดรูปแบบแหล่งที่มาคือ เว้นแต่ทุกคนจะใช้งาน PR ของนักพัฒนาจะมีการแก้ไขที่ไม่เกี่ยวข้องกับการเปลี่ยนแปลงเฉพาะของพวกเขา หรือแย่กว่านั้น การพยายามแก้ไขการจัดรูปแบบแหล่งที่มาเป็นระยะจะทำลายประวัติ git ของ repo ของคุณทุกครั้งที่คุณจัดรูปแบบแหล่งที่มา ดังนั้น หากจะใช้การจัดรูปแบบต้นฉบับ ก็ควรตรวจสอบในทุกโค้ดที่แตกต่างกันเพื่อให้แน่ใจว่าการจัดรูปแบบถูกต้อง
สำหรับตัวอย่างนี้ เราใช้ Astyle แต่รูปแบบ Clang ก็ใช้งานได้เช่นกัน เพื่อสนับสนุน Astyle ด้วยวิธีง่ายๆ เราได้จัดเตรียมเป้าหมาย make ที่ช่วยให้นักพัฒนาสามารถจัดรูปแบบซอร์สโค้ดของตนได้โดยการเรียกใช้ make format เพื่อที่จะทำสิ่งนี้ เราต้องได้รับ Astyle ก่อน:
list ( APPEND ASTYLE_CMAKE_ARGS
"-DCMAKE_INSTALL_PREFIX= ${CMAKE_BINARY_DIR} "
)
ExternalProject_Add(
astyle
GIT_REPOSITORY https://github.com/Bareflank/astyle.git
GIT_TAG v1.2
GIT_SHALLOW 1
CMAKE_ARGS ${ASTYLE_CMAKE_ARGS}
PREFIX ${CMAKE_BINARY_DIR} /astyle/ prefix
TMP_DIR ${CMAKE_BINARY_DIR} /astyle/tmp
STAMP_DIR ${CMAKE_BINARY_DIR} /astyle/stamp
DOWNLOAD_DIR ${CMAKE_BINARY_DIR} /astyle/download
SOURCE_DIR ${CMAKE_BINARY_DIR} /astyle/src
BINARY_DIR ${CMAKE_BINARY_DIR} /astyle/ build
)ตรรกะ cmake นี้ใช้ ExternalProject_Add เพื่อดาวน์โหลด Astyle โดยอัตโนมัติ คอมไพล์สำหรับแพลตฟอร์มของคุณ และติดตั้งลงในไดเร็กทอรี build ของคุณ เพื่อให้เป้าหมาย make แบบกำหนดเองของเราสามารถใช้งานได้ โปรดทราบว่าเราใช้ Astyle เวอร์ชันแพตช์ของเราเอง ซึ่งเปลี่ยนระบบบิลด์จากชุด Makefiles ที่กำหนดเองของ Astyle ไปเป็นระบบบิลด์ CMake เพื่อความเรียบง่าย
list ( APPEND ASTYLE_ARGS
--style=1tbs
--lineend=linux
-- suffix =none
--pad-oper
--unpad-paren
--break-closing-brackets
--align-pointer= name
--align-reference= name
--indent-preproc-define
--indent-switches
--indent-col1-comments
--keep-one-line-statements
--keep-one-line-blocks
--pad-header
--convert-tabs
--min-conditional-indent=0
--indent=spaces=4
--close-templates
--add-brackets
--break-after-logical
${CMAKE_SOURCE_DIR} / include /*.h
${CMAKE_SOURCE_DIR} /src/*.cpp
${CMAKE_SOURCE_DIR} / test /*.cpp
)
if ( NOT WIN32 STREQUAL "1" )
add_custom_target (
format
COMMAND ${CMAKE_SOURCE_DIR} /bin/astyle ${ASTYLE_ARGS}
COMMENT "running astyle"
)
else ()
add_custom_target (
format
COMMAND ${CMAKE_SOURCE_DIR} /bin/astyle.exe ${ASTYLE_ARGS}
COMMENT "running astyle"
)
endif ()ในการสร้างเป้าหมาย make astyle แบบกำหนดเอง เราใช้โค้ด CMake ด้านบน สิ่งนี้จะชี้ CMake ไปยังผลลัพธ์ไบนารี astyle ซึ่งขึ้นอยู่กับแพลตฟอร์ม และจัดเตรียม astyle ด้วยตัวเลือกการจัดรูปแบบและไฟล์ต้นฉบับเฉพาะสำหรับโปรเจ็กต์นี้
- cmake -DENABLE_ASTYLE=ON -DCMAKE_CXX_COMPILER="g++-6" ..
- make
- make format
- |
if [[ -n $(git diff) ]]; then
echo "You must run make format before submitting a pull request"
echo ""
git diff
exit -1
fi สุดท้ายนี้ เพื่อตรวจสอบในแต่ละ PR ว่าการเปลี่ยนแปลงโค้ดเป็นไปตามการกำหนดค่า Astyle ของเรา เราจะเพิ่มโค้ดด้านบนลงในสคริปต์ Travis CI ของเรา สิ่งนี้จะสร้างเป้าหมาย make format ของเราและดำเนินการเพื่อจัดรูปแบบโค้ด หาก make format แบบโค้ด ความแตกต่างจะถูกสร้างขึ้นซึ่งสามารถใช้ git diff ในการตรวจจับได้ หากไม่มีการสร้างความแตกต่าง แสดงว่าแหล่งที่มาทั้งหมดเป็นไปตามการกำหนดค่า Astyle ของเรา และการทดสอบก็ผ่าน
Clang Tidy ให้การวิเคราะห์แบบคงที่ การสนับสนุนสำหรับเครื่องมือนี้เริ่มต้นโดยการเพิ่มสิ่งต่อไปนี้ลงใน CMakeLists.txt:
set (CMAKE_EXPORT_COMPILE_COMMANDS ON )สิ่งนี้จะบอก CMake ให้บันทึกคำแนะนำการคอมไพล์ทั้งหมดที่ใช้ในการคอมไพล์โปรเจ็กต์ของคุณ รวมถึงแฟล็กและคำจำกัดความ Clang Tidy จะใช้ข้อมูลนี้เพื่อวิเคราะห์โปรเจ็กต์ของคุณแบบคงที่ในลักษณะเดียวกับที่รวบรวม ข้อดีของแนวทางนี้คือการปรับปรุงความแม่นยำอย่างมาก ข้อเสียเปรียบหลักของวิธีนี้คือ Clang Tidy ไม่เก่งในการวิเคราะห์ไฟล์แบบสแตติกที่ไม่แสดงในฐานข้อมูลการคอมไพล์นี้ (เช่น ไฟล์ส่วนหัว) ด้วยเหตุนี้ หากคุณต้องการวิเคราะห์ส่วนหัว จะต้องรวมไว้ในไฟล์ต้นฉบับที่รวมอยู่ในฐานข้อมูลการคอมไพล์
list ( APPEND RUN_CLANG_TIDY_BIN_ARGS
-clang-tidy-binary ${CLANG_TIDY_BIN}
-header- filter =.*
-checks=clan*,cert*,misc*,perf*,cppc*,read*,mode*,-cert-err58-cpp,-misc-noexcept-move-constructor
)
add_custom_target (
tidy
COMMAND ${RUN_CLANG_TIDY_BIN} ${RUN_CLANG_TIDY_BIN_ARGS}
COMMENT "running clang tidy"
) ในที่สุด Clang Tidy ก็ได้รับเป้าหมายของตัวเองเพื่อทำให้การใช้งานง่ายขึ้น ที่นี่เราจะบอกสคริปต์ run-clang-tidy-4.0.py ว่า clang tidy binary ใดที่จะใช้ รวมถึงการตรวจสอบใดที่จะดำเนินการ และไฟล์ส่วนหัวใดบ้างที่จะรวมไว้ ซึ่งก็คือไฟล์ทั้งหมด เราปิดการทดสอบ -cert-err58-cpp เนื่องจากทริกเกอร์โค้ดจาก catch.hpp และ -misc-noยกเว้น-move-constructor เนื่องจากยังคงมีข้อบกพร่องใน 4.0 โปรดทราบว่าเราเลือกเวอร์ชันเฉพาะของ Clang Tidy ซึ่งมีความสำคัญเนื่องจาก Clang Tidy เวอร์ชันใหม่แต่ละเวอร์ชันจะแก้ไขข้อบกพร่องและเพิ่มการตรวจสอบใหม่ ส่งผลให้ได้ผลลัพธ์ที่แตกต่างกันขึ้นอยู่กับเวอร์ชันที่คุณใช้
- cmake -DENABLE_CLANG_TIDY=ON -DCMAKE_CXX_COMPILER="g++-6" ..
- make
- make tidy > output.txt
- |
if [[ -n $(grep "warning: " output.txt) ]] || [[ -n $(grep "error: " output.txt) ]]; then
echo "You must pass the clang tidy checks before submitting a pull request"
echo ""
grep --color -E '^|warning: |error: ' output.txt
exit -1;
else
echo -e " 33[1;32mxE2x9Cx93 passed: 33[0m $1";
fiจาก Travis CI เราเปิดใช้งาน Clang Tidy และดัมพ์เอาต์พุตไปยังไฟล์ หากไฟล์นี้มี "คำเตือน" หรือ "ข้อผิดพลาด" แสดงว่าเราไม่ผ่านการทดสอบ และส่งออกปัญหาที่ Clang Tidy รายงานไปยังผู้ใช้เพื่อทำการแก้ไข เพื่อให้แน่ใจว่า PR ทุกรายการได้รับการตรวจสอบแบบคงที่
CppCheck เป็นอีกหนึ่งเครื่องมือวิเคราะห์แบบคงที่
list ( APPEND CPPCHECK_CMAKE_ARGS
"-DCMAKE_INSTALL_PREFIX= ${CMAKE_BINARY_DIR} "
)
ExternalProject_Add(
cppcheck
GIT_REPOSITORY https://github.com/danmar/cppcheck.git
GIT_TAG 1.79
GIT_SHALLOW 1
CMAKE_ARGS ${CPPCHECK_CMAKE_ARGS}
PREFIX ${CMAKE_BINARY_DIR} /external/cppcheck/ prefix
TMP_DIR ${CMAKE_BINARY_DIR} /external/cppcheck/tmp
STAMP_DIR ${CMAKE_BINARY_DIR} /external/cppcheck/stamp
DOWNLOAD_DIR ${CMAKE_BINARY_DIR} /external/cppcheck/download
SOURCE_DIR ${CMAKE_BINARY_DIR} /external/cppcheck/src
BINARY_DIR ${CMAKE_BINARY_DIR} /external/cppcheck/ build
)เวอร์ชันของ CppCheck ที่ให้บริการโดย Ubuntu 14.04 นั้นเก่าแล้ว และไม่รองรับ C++11 อย่างดี ดังนั้นเราจึงคว้า CppCheck เวอร์ชันเฉพาะจาก GitHub เพื่อให้ผู้ใช้ทุกคนในโปรเจ็กต์ใช้เวอร์ชันเดียวกันได้
list ( APPEND CPPCHECK_ARGS
--enable=warning,style,performance,portability,unusedFunction
--std=c++11
--verbose
--error-exitcode=1
-- language =c++
-DMAIN=main
-I ${CMAKE_SOURCE_DIR} / include
${CMAKE_SOURCE_DIR} / include /*.h
${CMAKE_SOURCE_DIR} /src/*.cpp
${CMAKE_SOURCE_DIR} / test /*.cpp
)
add_custom_target (
check
COMMAND ${CMAKE_BINARY_DIR} /bin/cppcheck ${CPPCHECK_ARGS}
COMMENT "running cppcheck"
)จากนั้นเราจะเพิ่มเป้าหมายที่กำหนดเองสำหรับแอปพลิเคชัน CppCheck ที่สร้างขึ้นใหม่ โดยแจ้งให้ CppCheck เปิดใช้งานการตรวจสอบทั้งหมด (ลบคำเตือนที่อวดรู้) และตรวจสอบไฟล์ต้นฉบับทั้งหมดของเรา โปรดทราบว่า CppCheck จำเป็นต้องรู้ว่า MAIN=main มิฉะนั้นจะคิดว่าฟังก์ชันหลักไม่ได้ถูกดำเนินการ และเราจำเป็นต้องแจ้งให้ CppCheck ทราบข้อผิดพลาดด้วยรหัสข้อผิดพลาดที่ไม่ใช่ 0 เพื่อให้ Travis CI รายงานการทดสอบที่ล้มเหลว หากมี การตรวจสอบล้มเหลว
- cmake -DENABLE_CPPCHECK=ON -DCMAKE_CXX_COMPILER="g++-6" ..
- make
- make checkการเรียกใช้การทดสอบ Travis CI นั้นง่ายดายพอๆ กับการเปิดใช้ CppCheck และเรียกใช้เป้าหมาย make แบบกำหนดเอง
Coverity Scan เป็นอีกหนึ่งเครื่องมือวิเคราะห์แบบคงที่ที่ดีมากในการค้นหาปัญหาเชิงโครงสร้างกับโค้ดของคุณที่หายาก หากคุณมีสิทธิ์เข้าถึง Coverity Scan การเพิ่ม SDP ของคุณก็คุ้มค่า
- os : linux
env :
- TEST="Coverity Scan"
addons :
apt :
sources :
- ubuntu-toolchain-r-test
packages :
- gcc-6
- g++-6
coverity_scan :
project :
name : " ainfosec/ci_helloworld "
description : " A simple example of how to setup a complete CI environment for C and C++ "
notification_email : [email protected]
build_command_prepend : " cmake -DCMAKE_CXX_COMPILER=g++-6 .. "
build_command : " make "
branch_pattern : master
script :
- echo -n | openssl s_client -connect scan.coverity.com:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | sudo tee -a /etc/ssl/certs/ca-Coverity Scan ยังติดตั้งง่ายอีกด้วย การทดสอบ Travis CI ข้างต้นเป็นการตัด/วางจากเว็บไซต์ของพวกเขาหลังจากที่คุณลงทะเบียนโครงการของคุณ สิ่งที่เราต้องทำคือคอมไพล์ซอร์สซึ่งบอก Coverity Scan ถึงวิธีการคอมไพล์ซอร์สโค้ด จากนั้น เว็บไซต์ของพวกเขาจะให้วิธีการยกเว้นไดเร็กทอรีและดูปัญหาเกี่ยวกับโค้ด ในตัวอย่างของเรา เราจะสแกนการเปลี่ยนแปลงทุกครั้งเป็นต้นแบบเนื่องจากจำนวนการเปลี่ยนแปลงในต้นแบบมีน้อย แต่สำหรับโปรเจ็กต์ขนาดใหญ่ที่มีการรวมจำนวนมากต่อวัน Coverity Scan แนะนำให้ใช้สาขา coverity_scan เฉพาะสำหรับการสแกน หากเสร็จสิ้น ควรตั้งค่าการสแกนทุกคืนโดยคว้าสาขาหลักแล้วดันไปที่สาขา coverity_scan ในแต่ละคืน ด้วยวิธีนี้ จึงสามารถระบุปัญหาเกี่ยวกับ Coverity Scan ได้อย่างรวดเร็ว
Codecov เป็นเครื่องมือครอบคลุมที่ทรงพลังแต่ติดตั้งง่าย
if (ENABLE_COVERAGE)
set ( CMAKE_CXX_FLAGS " ${CMAKE_CXX_FLAGS} -g " )
set ( CMAKE_CXX_FLAGS " ${CMAKE_CXX_FLAGS} -O0" )
set ( CMAKE_CXX_FLAGS " ${CMAKE_CXX_FLAGS} -fprofile-arcs" )
set ( CMAKE_CXX_FLAGS " ${CMAKE_CXX_FLAGS} -ftest-coverage" )
set ( CMAKE_EXE_LINKER_FLAGS " ${CMAKE_EXE_LINKER_FLAGS} --coverage" )
endif () ในการตั้งค่าความครอบคลุม เราต้องเปิดใช้งานการรองรับ GCOV ในคอมไพเลอร์ของเรา (สมมติว่า GCC หรือ Clang) เมื่อเปิดใช้งานการสนับสนุนนี้ การรัน make test จะสร้างสถิติความครอบคลุมที่ Codecov สามารถวิเคราะห์ได้ เพื่อแจ้งให้คุณทราบว่าโค้ดใดมีหรือยังไม่ได้ทดสอบหน่วย
- cmake -DENABLE_COVERAGE=ON -DCMAKE_CXX_COMPILER="g++-6" ..
- make
- make test
- cd ..
- bash <(curl -s https://codecov.io/bash)การทดสอบ Travis CI นั้นง่ายดายเพียงแค่คอมไพล์และรันการทดสอบหน่วย จากนั้นเรียกใช้ bash script ของ Codecov เมื่อเสร็จแล้ว สามารถดูผลลัพธ์ได้บนเว็บไซต์ของ Codecov
Coveralls เป็นอีกหนึ่งเครื่องมือในการปกปิด
if (ENABLE_COVERAGE)
set ( CMAKE_CXX_FLAGS " ${CMAKE_CXX_FLAGS} -g " )
set ( CMAKE_CXX_FLAGS " ${CMAKE_CXX_FLAGS} -O0" )
set ( CMAKE_CXX_FLAGS " ${CMAKE_CXX_FLAGS} -fprofile-arcs" )
set ( CMAKE_CXX_FLAGS " ${CMAKE_CXX_FLAGS} -ftest-coverage" )
set ( CMAKE_EXE_LINKER_FLAGS " ${CMAKE_EXE_LINKER_FLAGS} --coverage" )
endif ()เช่นเดียวกับ Codecov จะต้องเปิดใช้งาน GCOV
- pip install --user git+git://github.com/eddyxu/cpp-coveralls.git
- cmake -DENABLE_COVERAGE=ON -DCMAKE_CXX_COMPILER="g++-6" ..
- make
- make test
- cd ..
- |
coveralls --build-root build --gcov-options '-lp'
-e build/external
-e build/include
-e build/CMakeFiles/3.8.0
-e build/CMakeFiles/feature_tests.c
-e build/CMakeFiles/feature_tests.cxxต่างจาก Codecov ตรงที่ Coveralls ติดตั้งยากกว่ามาก Codecov ติดตามว่าไฟล์ใดบ้างที่อยู่ในพื้นที่เก็บข้อมูล git ของคุณ และสร้างเฉพาะรายงานสำหรับไฟล์ใน repo ในขณะที่ Coveralls จะสร้างรายงานความครอบคลุมสำหรับไฟล์ทั้งหมดที่เห็น รวมถึงไฟล์ที่สร้างโดย CMake นอกจากนี้ Coveralls ยังไม่มีสคริปต์ทุบตีอย่างง่ายในการรายงานข้อมูลการครอบคลุมไปยังเซิร์ฟเวอร์ แต่จำเป็นต้องติดตั้งเครื่องมือเฉพาะ C++ ภายนอกเพื่อรวบรวมข้อมูล GCOV แทน ด้วยเหตุผลเหล่านี้ เราจึงต้องติดตั้ง cpp-coveralls แล้วบอกให้ยกเว้นไฟล์/ไดเร็กทอรีเฉพาะที่ไม่ควรรวบรวมไว้
Google Sanitizers เป็นเครื่องมือวิเคราะห์แบบไดนามิกที่รวมอยู่ใน GCC และ Clang/LLVM
if (ENABLE_ASAN)
set ( CMAKE_CXX_FLAGS " ${CMAKE_CXX_FLAGS} -g" )
set ( CMAKE_CXX_FLAGS " ${CMAKE_CXX_FLAGS} -O1" )
set ( CMAKE_CXX_FLAGS " ${CMAKE_CXX_FLAGS} -fuse-ld=gold" )
set ( CMAKE_CXX_FLAGS " ${CMAKE_CXX_FLAGS} -fno-omit-frame-pointer" )
set ( CMAKE_CXX_FLAGS " ${CMAKE_CXX_FLAGS} -fsanitize=address" )
set ( CMAKE_CXX_FLAGS " ${CMAKE_CXX_FLAGS} -fsanitize=leak" )
endif ()
if (ENABLE_USAN)
set ( CMAKE_CXX_FLAGS " ${CMAKE_CXX_FLAGS} -fuse-ld=gold" )
set ( CMAKE_CXX_FLAGS " ${CMAKE_CXX_FLAGS} -fsanitize=undefined" )
endif ()
if (ENABLE_TSAN)
set ( CMAKE_CXX_FLAGS " ${CMAKE_CXX_FLAGS} -fuse-ld=gold" )
set ( CMAKE_CXX_FLAGS " ${CMAKE_CXX_FLAGS} -fsanitize=thread" )
endif ()น้ำยาฆ่าเชื้อแต่ละชนิดต้องแยกออกจากกัน ดังนั้นเราจึงมีการทดสอบหนึ่งครั้งต่อกลุ่มน้ำยาฆ่าเชื้อ ธงสำหรับแต่ละชุดสามารถพบได้ในหน้า GitHub ของ Google รวมถึงเอกสารการใช้งานของ Clang
- cmake -DENABLE_ASAN= ON -DCMAKE_CXX_COMPILER= "g++-6" ..
- make
- make testสำหรับการทดสอบแต่ละครั้ง เราจะเปิดการตรวจสอบเฉพาะ และการทดสอบหน่วย และหากการตรวจสอบล้มเหลว การทดสอบหน่วยจะออกด้วยรหัสทางออกที่ไม่ใช่ 0 ส่งผลให้ Travis CI ไม่ผ่านการทดสอบ ควรสังเกตว่า GCC และ Clang เวอร์ชันใหม่แต่ละเวอร์ชันมาพร้อมกับการรองรับที่ดีกว่า ดังนั้น เช่นเดียวกับเครื่องมืออื่นๆ คุณควรยึดติดกับเวอร์ชันเฉพาะ
Valgrind เป็นอีกหนึ่งเครื่องมือวิเคราะห์แบบไดนามิกที่ให้การตรวจจับการรั่วไหล
set (MEMORYCHECK_COMMAND_OPTIONS " ${MEMORYCHECK_COMMAND_OPTIONS} --leak-check=full" )
set (MEMORYCHECK_COMMAND_OPTIONS " ${MEMORYCHECK_COMMAND_OPTIONS} --track-fds=yes" )
set (MEMORYCHECK_COMMAND_OPTIONS " ${MEMORYCHECK_COMMAND_OPTIONS} --trace-children=yes" )
set (MEMORYCHECK_COMMAND_OPTIONS " ${MEMORYCHECK_COMMAND_OPTIONS} --error-exitcode=1" )วิธีที่ง่ายที่สุดในการรัน Valgrind คือการใช้การสนับสนุนในตัวของ CMake เนื่องจากจะจัดการตรรกะข้อผิดพลาดให้กับคุณ ด้วยเหตุผลนี้ เราจำเป็นต้องบอก CMake ว่าควรมอบแฟล็กใดบ้างให้กับ Valgrind ในกรณีนี้ เราเปิดใช้งานการตรวจสอบทั้งหมดและแจ้งให้ Valgrind ออกด้วยโค้ดทางออกที่ไม่ใช่ 0 เพื่อว่าหากการตรวจสอบล้มเหลว Travis CI จะไม่ผ่านการทดสอบ
- cmake -DCMAKE_CXX_COMPILER="g++-6" ..
- make
- ctest -T memcheckในการรันการทดสอบ สิ่งที่เราต้องทำคือคอมไพล์โค้ด และรันการทดสอบหน่วยโดยใช้ ctest เพื่อเปิดใช้งานโหมด memcheck
โครงการนี้ได้รับอนุญาตภายใต้ใบอนุญาต MIT
