
אוהבים GitLab ושונאים באגים? רוצה לשפר את איכות קוד המקור שלך? אז הגעתם למקום הנכון. היום נספר לכם כיצד להגדיר את מנתח PVS-Studio C# לבדיקת בקשות מיזוג. שיהיה לך מצב רוח של חד קרן וקריאה מהנה לכולם.
— הוא כלי לזיהוי שגיאות ופגיעויות פוטנציאליות בקוד המקור של תוכניות שנכתבו ב-C, C++, C# ו-Java. הוא פועל על מערכות 64 סיביות. Windows, Linux и macOSהוא יכול לנתח קוד המכוון לפלטפורמות ARM של 32 סיביות, 64 סיביות ומוטמעות.
אגב, הוצאנו את PVS-Studio 7.08, שבו עשינו הרבה דברים . לדוגמא:
- מנתח C# תחת Linux и macOS;
- תוסף עבור Rider;
- מצב בדיקת רשימת קבצים חדשה.
מצב בדיקת רשימת קבצים
בעבר, על מנת לבדוק קבצים מסוימים, היה צורך להעביר .xml עם רשימת קבצים לנתח. אבל מכיוון שזה לא מאוד נוח, הוספנו את היכולת להעביר .txt, מה שהופך את החיים לפשוטים מאוד.
על מנת לבדוק קבצים ספציפיים, עליך לציין את הדגל --קבצי המקור (-f) והעבר .txt עם רשימה של קבצים. זה נראה כמו זה:
pvs-studio-dotnet -t path/to/solution.sln -f fileList.txt -o project.jsonאם אתה מעוניין להגדיר commit checking או pull requests, אתה יכול גם לעשות זאת באמצעות מצב זה. ההבדל יהיה בקבלת רשימה של קבצים לניתוח ותלוי באילו מערכות אתה משתמש.
עקרון בדיקת בקשת מיזוג
המהות העיקרית של הבדיקה היא להבטיח שבעיות שזוהו על ידי המנתח במהלך המיזוג לא ייפלו לתוך אב ענף. אנחנו גם לא רוצים לנתח את כל הפרויקט בכל פעם. יתרה מכך, בעת מיזוג סניפים, יש לנו רשימה של קבצים שהשתנו. לכן, אני מציע להוסיף בדיקת בקשת מיזוג.
כך נראית בקשת מיזוג לפני יישום מנתח סטטי:

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

אנחנו מנתחים שינויים 2 ואם אין שגיאות, אנו מקבלים את בקשת המיזוג, אחרת אנו דוחים אותה.
אגב, אם אתה מעוניין לנתח commits ו-pull requests עבור C/C++, אז אתה יכול לקרוא על זה .
GitLab
הוא כלי מחזור חיים מבוסס קוד פתוח של DevOps המספק מערכת ניהול מאגר קוד עבור Git עם wiki משלה, מערכת מעקב אחר בעיות, צינור CI/CD ותכונות אחרות.
לפני שתתחיל לנתח בקשות מיזוג, עליך להירשם ולהעלות את הפרויקט שלך. אם אתה לא יודע איך לעשות את זה, אז אני מציע חברי לעבודה.
שים לב. שיטת הקמת הסביבה המתוארת להלן היא אחת האפשריות. המטרה היא להציג את השלבים להגדרת הסביבה הדרושה לניתוח ולהשקת הנתח. אולי במקרה שלך יהיה אופטימלי יותר להפריד בין שלבי הכנת הסביבה (הוספת מאגרים, התקנת מנתח) וניתוח: למשל, הכנת תמונות Docker עם הסביבה הדרושה ושימוש בהן, או שיטה אחרת.
כדי להבין טוב יותר מה יקרה עכשיו, אני מציע להסתכל על הדיאגרמה הבאה:

המנתח דורש .NET Core SDK 3, לכן לפני התקנת המנתח, עליך להוסיף את מאגרי Microsoft שמהם יותקנו התלויות של המנתח. הוספת מאגרי Microsoft עבור הפצות שונות Linux .
כדי להתקין את PVS-Studio דרך מנהל החבילות, תצטרך להוסיף גם את מאגרי ה-PVS-Studio. הוספת מאגרים עבור הפצות שונות מתוארת ביתר פירוט ב .
המנתח דורש מפתח רישיון כדי לפעול. אתה יכול לקבל רישיון ניסיון ב .
שים לב. שימו לב שאופן הפעולה המתואר (ניתוח בקשות מיזוג) מחייב רישיון Enterprise. לכן, אם אתה רוצה לנסות את אופן הפעולה הזה, אל תשכח לציין בשדה "הודעה" שאתה צריך רישיון Enterprise.
אם מתרחשת בקשת מיזוג, אז אנחנו צריכים רק לנתח את רשימת הקבצים שהשתנו, אחרת אנחנו מנתחים את כל הקבצים. לאחר הניתוח, עלינו להמיר את היומנים לפורמט שאנו צריכים.
כעת, כשאלגוריתם העבודה לנגד עיניך, אתה יכול לעבור לכתיבת תסריט. כדי לעשות זאת, עליך לשנות את הקובץ .gitlab-ci.yml או, אם הוא לא קיים, צור אותו. כדי ליצור אותו, עליך ללחוץ על שם הפרויקט שלך -> הגדר CI/CD.

עכשיו אנחנו מוכנים לכתוב את התסריט. בוא נכתוב תחילה את הקוד שיתקין את הנתח ונזין את הרישיון:
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מכיוון שההתקנה וההפעלה חייבים להתרחש לפני כל שאר הסקריפטים, אנו משתמשים בתווית מיוחדת לפני_סקריפט. הרשו לי להסביר מעט את הפרגמנט הזה.
מתכוננים להתקנת הנתח:
- 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 ומנתח:
- 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$PVS_NAME - שם משתמש.
$PVS_KEY - מפתח מוצר.
שחזור תלות בפרויקט היכן $CI_PROJECT_DIR - נתיב מלא לספריית הפרויקט:
- dotnet restore "$CI_PROJECT_DIR"/Path/To/Solution.slnלצורך ניתוח נכון, יש לבנות את הפרויקט בהצלחה, ולשחזר את התלות שלו (לדוגמה, יש להוריד את חבילות NuGet הדרושות).
ניתן להגדיר משתני סביבה המכילים מידע על רישיון על ידי לחיצה הגדרת, ואחרי - הלאה CI/CD.

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

עכשיו אתה יכול לעבור לניתוח. ראשית, בואו נוסיף סקריפט לניתוח מלא. אל הדגל -t אנחנו מעבירים את השביל לפתרון הדגל -o כתוב את הנתיב לקובץ בו ייכתבו תוצאות הניתוח. אנו מעוניינים גם בקוד ההחזרה. במקרה זה, אנו מעוניינים שהפעולה תיפסק כאשר קוד ההחזרה מכיל מידע על כך שהוצאו אזהרות במהלך הניתוח. כך נראה הפרגמנט הזה:
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קודי החזרה פועלים על פי עקרון מסיכת סיביות. לדוגמה, אם הניתוח הביא לאזהרות, קוד ההחזרה יהיה 8. אם הרישיון יפוג תוך חודש, קוד ההחזרה יהיה 4. אם הניתוח זיהה שגיאות והרישיון יפוג תוך חודש, קוד ההחזרה יכיל את שני הערכים: חברו את המספרים יחד כדי לקבל את קוד ההחזרה הסופי - 8 + 4 = 12. לפיכך, על ידי בדיקת הביטים המתאימים, ניתן לקבל מידע על מצבים שונים במהלך הניתוח. קודי החזרה מתוארים ביתר פירוט בסעיף "קודי החזרה של pvs-studio-dotnet".Linux / macOS)" מסמך"".
במקרה זה, אנו מעוניינים בכל קודי ההחזרה שבהם מופיע 8.
- exit_code=$((($exit_code & 8)/8))נקבל 1 כאשר קוד ההחזרה מכיל את הביט של המספר שאנו מעוניינים בו, אחרת נקבל 0.
הגיע הזמן להוסיף ניתוח בקשות מיזוג. לפני שנעשה זאת, בואו נכין מקום לתסריט. אנחנו צריכים שזה יתבצע רק כאשר מתרחשת בקשת מיזוג. זה נראה כמו זה:
merge:
script:
only:
- merge_requestsנעבור לתסריט עצמו. עמדתי בפני העובדה שהמכונה הוירטואלית לא יודעת עליה כלום מקור / אדון. אז בואו נעזור לה קצת:
- git fetch originכעת נקבל את ההבדל בין הענפים ונשמור את התוצאה פנימה txt קוֹבֶץ:
- git diff --name-only origin/master $CI_COMMIT_SHA > pvs-fl.txtשם $CI_COMMIT_SHA - Hash של ה-commit האחרון.
לאחר מכן, אנו מתחילים לנתח את רשימת הקבצים באמצעות הדגל -f. אנו מעבירים אליו את קובץ ה-.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הסקריפט המלא לבדיקת בקשת מיזוג ייראה כך:
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כל מה שנותר הוא להוסיף המרת יומן לאחר עיבוד כל הסקריפטים. אנו משתמשים בתווית after_script ושימושיות ממיר-plog:
after_script:
- plog-converter -t html -o eLog ./PVS-Studio.jsonשירות הוא פרויקט קוד פתוח המשמש להמרת דוחות שגיאות מנתח לצורות שונות, כגון HTML. תיאור מפורט יותר של השירות ניתן בסעיף המשנה "כלי לממיר Plog" .
אגב, אם אתה רוצה לעבוד בצורה נוחה עם דוחות .json באופן מקומי מה-IDE, אז אני מציע שלנו עבור IDE Rider. השימוש בו מתואר ביתר פירוט ב .
מטעמי נוחות, הנה זה .gitlab-ci.yml במלואו:
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לאחר שהוספת הכל לקובץ, לחץ על התחייב בשינויים. על מנת לראות שהכל תקין, עבור אל CI / CD -> צינורות -> ריצה. ייפתח חלון מכונה וירטואלית, שבסופו אמורים להיות הדברים הבאים:

ראה איוב הצליח - הצלחה, הכל בסדר. עכשיו אתה יכול לבדוק מה עשית.
דוגמאות לעבודה
לדוגמא לעבודה, בואו ניצור פרויקט פשוט (ב אב) שיכיל מספר קבצים. לאחר מכן, בסניף אחר נשנה רק קובץ אחד וננסה לבצע בקשת מיזוג.
הבה נבחן שני מקרים: כאשר הקובץ ששונה מכיל שגיאה ומתי לא. ראשית, דוגמה עם שגיאה.
נניח שיש קובץ בסניף המאסטר Program.cs, שאינו מכיל שגיאות, אך בענף אחר הוסיף המפתח קוד שגוי ורוצה לבצע בקשת מיזוג. איזו טעות הוא עשה לא כל כך חשובה, העיקר שהיא קיימת. לדוגמה, המפעיל שכח לזרוק (כן, ):
void MyAwesomeMethod(String name)
{
if (name == null)
new ArgumentNullException(....);
// do something
....
}בואו נסתכל על התוצאה של ניתוח דוגמה עם שגיאה. כמו כן כדי לוודא שרק קובץ אחד מנותח, הוספתי את הדגל -r לקו ההשקה של pvs-studio-dotnet:

אנו רואים שהנתח מצא שגיאה ולא איפשר מיזוג סניפים.
בואו נבדוק את הדוגמה ללא שגיאה. תיקון הקוד:
void MyAwesomeMethod(String name)
{
if (name == null)
throw new ArgumentNullException(....);
// do something
....
}מיזוג תוצאות ניתוח בקשות:

כפי שאנו יכולים לראות, לא נמצאו שגיאות, וביצוע המשימה הצליח, וזה מה שרצינו לבדוק.
מסקנה
ניכוש קוד רע לפני מיזוג סניפים הוא מאוד נוח ונעים. אז אם אתה משתמש ב-CI/CD, נסה להטמיע מנתח סטטי כדי לבדוק. יתר על כן, זה נעשה בצורה פשוטה למדי.
תודה על תשומת הלב שלך.
אם אתה רוצה לשתף מאמר זה עם קהל דובר אנגלית, אנא השתמש בקישור התרגום: ניקולאי מירונוב. .
מקור: www.habr.com
