ניתוח של התחייבויות ובקשות משיכה ב-Travis CI, Buddy ו-AppVeyor באמצעות PVS-Studio

ב-PVS-Studio Analyzer לשפות C ו-C++ בלינוקס וב-macOS, החל מגרסה 7.04, הופיעה אפשרות בדיקה לבדיקת רשימת הקבצים שצוינו. באמצעות המצב החדש, אתה יכול להגדיר את הנתח לבדיקת התחייבויות ובקשות משיכה. מאמר זה יספר לכם כיצד להגדיר את בדיקת רשימת הקבצים שהשתנו של פרויקט GitHub במערכות CI (Intinuous Integration) פופולריות כמו Travis CI, Buddy ו-AppVeyor.

מצב בדיקת רשימת קבצים

סטודיו PVS הוא כלי לזיהוי שגיאות ופגיעויות פוטנציאליות בקוד המקור של תוכניות הכתובות ב-C, C++, C# ו-Java. עובד על מערכות 64 סיביות ב-Windows, Linux ו-macOS.

בגרסה PVS-Studio 7.04 עבור לינוקס ו-macOS, הופיע מצב לבדיקת רשימת קבצי המקור. זה עובד עבור פרויקטים שמערכת הבנייה שלהם מאפשרת לך ליצור קובץ compile_commands.json. יש צורך במנתח כדי לחלץ מידע על הידור של הקבצים שצוינו. אם מערכת הבנייה שלך לא תומכת ביצירת הקובץ compile_commands.json, אתה יכול לנסות ליצור קובץ כזה באמצעות כלי השירות דוב.

כמו כן, ניתן להשתמש במצב בדיקת רשימת הקבצים יחד עם יומן ה-strace trace של השקות מהדר (pvs-studio-analyzer trace). כדי לעשות זאת, תחילה תצטרך לבצע בנייה מלאה של הפרויקט ולעקוב אחריו כך שהנתח יאסוף מידע מלא על פרמטרי ההידור של כל הקבצים הנבדקים.

עם זאת, לאפשרות זו יש חיסרון משמעותי - תצטרכו לבצע מעקב בנייה מלא של הפרויקט כולו בכל פעם שתפעילו אותו, מה כשלעצמו סותר את הרעיון של בדיקה מהירה של commit. לחלופין, אם אתה מאחסן את תוצאת המעקב עצמה, הריצות הבאות של המנתח עשויות להיות חלקיות אם מבנה התלות של קובצי המקור משתנה לאחר המעקב (לדוגמה, נוסף #include חדש לאחד מקבצי המקור).

לכן, איננו ממליצים להשתמש במצב בדיקת רשימת הקבצים עם יומן המעקב לבדיקת commits או pull requests. במקרה שאתה יכול לבצע בנייה מצטברת בעת בדיקת commit, שקול להשתמש במצב ניתוח מצטבר.

רשימת קבצי המקור לניתוח נשמרת בקובץ טקסט ומועברת לנתח באמצעות הפרמטר -S:

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

קובץ זה מציין נתיבים יחסיים או מוחלטים לקבצים, וכל קובץ חדש חייב להיות בשורה חדשה. מקובל לציין לא רק שמות קבצים לניתוח, אלא גם טקסטים שונים. המנתח יראה שזה לא קובץ ויתעלם מהשורה. זה יכול להיות שימושי להערות אם קבצים מצוינים באופן ידני. עם זאת, לעתים קרובות תיווצר רשימה של קבצים במהלך הניתוח ב-CI, למשל, אלה יכולים להיות קבצים מבקשת commit או pull.

כעת, באמצעות מצב זה, אתה יכול לבדוק במהירות קוד חדש לפני שהוא נכנס לענף הפיתוח הראשי. כדי להבטיח שמערכת הסריקה מגיבה לאזהרות מנתח, תוכנית השירות ממיר-plog דגל נוסף --לציין-אזהרות:

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

עם דגל זה, הממיר יחזיר קוד שאינו אפס אם יש אזהרות בדוח הנתח. באמצעות קוד ההחזרה, אתה יכול לחסום בקשת הוק, התחייבות או משיכה מראש, וניתן להציג, לשתף או לשלוח את דוח הנתח שנוצר בדוא"ל.

הערה. כאשר אתה מתחיל לראשונה לנתח רשימה של קבצים, הפרויקט כולו ינותח, כי המנתח צריך ליצור קובץ תלות של קבצי מקור הפרויקט בקבצי הכותרות. זוהי תכונה של ניתוח קבצי C ו-C++. בעתיד, ניתן יהיה לשמור את קובץ התלות במטמון והוא יעודכן אוטומטית על ידי המנתח. היתרון של בדיקת commits בעת שימוש במצב בדיקת רשימת הקבצים במקום שימוש במצב הניתוח המצטבר הוא שאתה צריך רק לשמור את הקובץ הזה במטמון ולא את קבצי האובייקט.

עקרונות כלליים של ניתוח בקשת משיכה

ניתוח הפרויקט כולו לוקח הרבה זמן, ולכן הגיוני לבדוק רק חלק מסוים ממנו. הבעיה היא שאתה צריך להפריד את הקבצים החדשים משאר קבצי הפרויקט.

בואו נסתכל על דוגמה של עץ commit עם שני ענפים:

בואו נדמיין את ההתחייבות הזו A1 מכיל כמות די גדולה של קוד שכבר נבדק. קצת קודם עשינו סניף מהקוממיט A1 ושינה כמה קבצים.

אתה, כמובן, שמת לב לזה אחרי A1 התרחשו עוד שתי התחייבויות, אבל אלה היו גם מיזוגים של סניפים אחרים, כי אנחנו לא מתחייבים אב. ועכשיו הגיע הזמן מתי תיקון חם מוּכָן. לכן הופיעה בקשת משיכה למיזוג B3 и A3.

כמובן שניתן יהיה לבדוק את כל תוצאת המיזוג שלהם, אך הדבר ייקח זמן רב מדי ולא מוצדק, שכן רק מספר קבצים שונו. לכן, יעיל יותר לנתח רק את אלה שהשתנו.

לשם כך, נקבל את ההבדל בין הענפים, בהיותנו בראש הענף שממנו אנו רוצים להתמזג למאסטר:

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 (--לציין-אזהרות). אם יש לפחות אזהרת מנתח אחת, קוד השירות מחזיר ממיר-plog ישתנה ל-2, אשר בתורו יודיע לשירות CI על נוכחותן של שגיאות פוטנציאליות בקבצי בקשת המשיכה.

טרוויס CI

התצורה נעשית כקובץ .travis.yml. מטעמי נוחות, אני ממליץ לך לשים הכל בסקריפט bash נפרד עם פונקציות שייקראו מהקובץ .travis.yml (bash script_name.sh function_name).

נוסיף את הקוד הדרוש לסקריפט בכתובת לחבוט, כך נקבל יותר פונקציונליות. בסעיף להתקין בוא נכתוב את הדברים הבאים:

install:
  - bash .travis.sh travis_install

אם היו לך הוראות כלשהן, תוכל להעביר אותן לתסריט, ולהסיר את המקפים.

בואו נפתח את הקובץ .travis.sh ולהוסיף את הגדרת הנתח לפונקציה 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 
}

עכשיו בואו נוסיף לקטע תסריט הפעל ניתוח:

script:
  - bash .travis.sh travis_script

ובתסריט הבאש:

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-Studio/:

cache:
  directories:
    - .PVS-Studio/

יש להוסיף את הקוד הזה לקובץ .travis.yml. ספרייה זו מאחסנת נתונים שונים שנאספו לאחר ניתוח, מה שיאיץ משמעותית את הריצות הבאות של ניתוח רשימת קבצים או ניתוח מצטבר. אם זה לא נעשה, אז המנתח למעשה מנתח את כל הקבצים בכל פעם.

באדי

כמו Travis 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_EXECUTION_PULL_REQEUST_NO - מספר בקשה למשוך;
• $BUDDY_REPO_SLUG - שילוב של שם משתמש ומאגר (לדוגמה max/test).

כעת נשמור את השינויים באמצעות הכפתור למטה ונאפשר ניתוח של בקשת המשיכה:

שלא כמו Travis CI, אנחנו לא צריכים לפרט .pvs-studio עבור שמירה במטמון, שכן Buddy שומר באופן אוטומטי את כל הקבצים עבור השקות עוקבות. לכן, הדבר האחרון שנותר הוא לשמור את הכניסה והסיסמה של PVS-Studio ב- Buddy. לאחר שמירת השינויים, נחזור ל-Pipeline. עלינו לעבור להגדרת משתנים והוספת כניסה ומפתח עבור PVS-Studio:

לאחר מכן, הופעת בקשת משיכה חדשה או התחייבות תפעיל את הביקורת. אם התחייבות מכילה שגיאות, באדי יציין זאת בדף בקשת המשיכה.

AppVeyor

הגדרת AppVeyor דומה ל-Baddy, מכיוון שהכל קורה בממשק האינטרנט ואין צורך להוסיף קובץ *.yml למאגר הפרויקטים.

בוא נעבור ללשונית הגדרות בסקירת הפרויקט:

בואו נגלול למטה בדף זה ונאפשר שמירת מטמון לאיסוף בקשות משיכה:

כעת נעבור ללשונית Environment, שם אנו מציינים את התמונה להרכבה ואת משתני הסביבה הדרושים:

אם קראת את הסעיפים הקודמים, אתה מכיר היטב את שני המשתנים האלה - 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, אתה רק צריך לציין את התיקיה בהגדרות; אבל איפשהו אתה צריך ליצור מפתחות ייחודיים ולנסות לשכנע את המערכת לתת לך את ההזדמנות להחליף את הפרגמנט השמור. לכן, אם ברצונך להגדיר ניתוח של בקשות משיכה בשירות אינטגרציה מתמשך שלא נדון לעיל, תחילה ודא שלא יהיו לך בעיות ב-caching.

תודה לך על תשומת הלב. אם משהו לא מסתדר, אתה מוזמן לכתוב לנו בכתובת תמיכה. אנו ייעץ ונעזור.

אם אתה רוצה לשתף את המאמר הזה עם קהל דובר אנגלית, אנא השתמש בקישור התרגום: מקסים Zvyagintsev. ניתוח של התחייבויות ובקשות משיכה ב-Travis CI, Buddy ו-AppVeyor באמצעות PVS-Studio.

מקור: www.habr.com