שימוש ב-husky לאכיפת git hooks

כך אני אוכף הרצה מקומית של בדיקות שונות לפני שהמתכנת עושה push
כלב האסקי

אחד מהכלים השימושיים ביותר שאני מכיר הוא githooks. אם אתם לא רוצים להכנס לקישור, זו פשוט דרך להריץ משימות לפני כל פעולה שאנחנו עושים בגיט (בין אם אנחנו משתמשים ב-CLI או ב-GUI כלשהו). כך למשל, אני יכול לאכוף הרצת בדיקת קוד סטטית לפני push במחשב במקומי של המתכנת.

נכון, זה נראה קצת מיותר כאשר אנחנו חושבים על זה, כי אם גם ככה יש לנו תהליך בילד מסודר (עם TravisCI למשל, או עם ג'נקינס), למה אני צריך לאכוף את כל העניין הזה לוקלית? מה אכפת לי אם המתכנת יבדוק שהקוד שלו עובר את הבדיקה הסטטית, או עובר בדיקות, לפני הבילד? גם ככה הוא לא יוכל לעשות merge אם הבילד נופל. התשובה היא כמעט מובנת מאליה: בילדים לוקחים זמן והרבה פעמים הבדיקות הסטטיות מתקיימות רק בסוף שלבים ארוכים ודקות ארוכות של פעולות. הרבה מתכנתים מבצעים push ויוצרים פול ריקווסט ואז מחכים שהבילד יעבור. לחכות כמה דקות ואז לראות שהבילד נופל על שטויות של 'שכחת נקודה פסיק בסוף' מבאסות עד מאוד ומבזבזות זמן שבמצטבר יכול להגיע לשעות רבות. בנוסף, אם אנחנו ממהרים להכניס תיקון לבאג משמעותי, הבילד שנופל לקראת הסוף על שטויות יכול להיות מאוד מתסכל.

זו הסיבה שאני משתדל לאכוף גם בדיקת קוד סטטית וגם הרצת בדיקות אוטומטיות כבר ב-push עם hook. מה הבעיה? כפי שציינתי במאמר שקישרתי אליו בהתחלה, הספריה שבה נמצא githooks היא ספרית git. , ספריה שלא נכנסת לפרויקט ולא יכולה להכנס אליו. אז איך אני יכול לאכוף כזה דבר? בקלות עם המודול husky. המודול כתוב כמובן ב-node.js, אבל זה לא משנה. מקובל היום שכל פרויקט נעזר בתשתית של node לבדיקות e2e, בדיקות קוד ושירותים אחרים כמו מיניפקציה, טרנספילציה של SASS\LESS או כל דרעק אחר. אז גם אם הפרויקט שלכם ב-asp.net או ב-PHP אפשר בהחלט להשתמש ב-husky ובכלל להכיר יותר את האקוסיסטם של node ומה הוא יכול לעשות עבורכם.

husky הוא מודול קטן ונחמד שמתקינים אותו בדיוק כמו כל מודול. חשוב שהוא יהיה ב-devDependencies, זו הסיבה שאנחנו מתקינים אותו כך:

npm install husky --save-dev

אחרי שאנחנו מתקינים אותו ומוודאים שהוא אכן נכנס ל-package.json, מהרגע הזה, כל מה שאנחנו צריכים זה להכניס לתוך חלק ה-scripts ב-package.json שלנו את השם של ה-git hook שאנחנו רוצים להשתמש בו והפקודה שתרוץ. למשל:


  "scripts": {
    "test": "xo && nyc ava",
    "prepush": "npm test"
  }

כאן בחרתי להשתמש ב-prepush. והכנסתי את הפקודה:

npm test

מה שקורה הוא שמהרגע שאני מכניס את הפקודה הזו, בכל פעם שאני עושה push, מה שירוץ זה npm test. אם npm test נכשלת, אין push. אני יכול להכניס כפקודה כל פקודה bash רגילה שאני יכול להריץ מה-CLI (ולא משנה אם זה לינוקס, מק או חלונות). למשל:


  "scripts": {
    "test": "xo && nyc ava",
    "prepush": "npm test && node ./cli.js sample-configuration.json"
  }

הפקודה היותר מסובכת הזו תרוץ לפני push. אם היא תיכשל, אין push. שימושי, נכון?

אני יכול להשתמש במגוון git hooks. השימושיים ביותר הם prepush שמתרחשת לפני git push ו-precommit שמתרחשת לפני git commit.

אפשר כמובן לדבג את הפקודה כמו כל פקודה ב-package.json scripts. למשל:

npm run precommit

אבל האמת היא שמעולם לא היתה לי איזושהי בעיה עם husky. ברגע שאני מכניס אותו לפרויקט והוא ב-package.json ומתכנת שמוריד את הפרויקט עושה npm install, נגמר הסיפור. כמובן שאפשר לעקוף את הרצת git hooks באמצעות התג no-verify, אבל רוב המתכנתים השפויים לא עושים את זה. כך אנחנו מקבלים פחות בילדים שנופלים על שטויות. פחות זמן שמתבזבז ומתכנתים שיודעים ואוהבים להריץ בדיקות בסיסיות גם באופן לוקלי.

אני משתמש ב-husky בכל הפרויקטים שלי, מי שרוצה לראות ממש דוגמה, יכול לראות אותה פה.

פוסטים נוספים שכדאי לקרוא

פתרונות ומאמרים על פיתוח אינטרנט

המנעו מהעלאת source control לשרת פומבי

לא תאמינו כמה אתרים מעלים את ה-source control שלהם לשרת. ככה תמצאו אותם וגם הסבר למה זה רעיון רע.

תמונה מצוירת של רובוט שמנקה HTML
יסודות בתכנות

סניטציה – למה זה חשוב

הסבר על טכניקה פשוטה וידועה מאד שאנו מפעילים על מידע לפני שאנחנו מציגים אותו ב-HTML באפליקציה או באתר.

גלילה לראש העמוד