Claude Code ב-GitLab CI/CD: אוטומציה בצנרת הבנייה

מאת צוות מדיה דיל · 08.08.2026 · AI · 8 דק׳

איך מטמיעים את Claude Code בתוך .gitlab-ci.yml כדי שאזכור @claude ב-issue או ב-MR יפתח Merge Request אוטומטי - הקמה, אבטחת מפתחות API ותרחיש שימוש אמיתי לצוות.

אם הצוות שלכם עובד עם GitLab וכבר מכיר את Claude Code בטרמינל, השלב הבא הטבעי הוא להכניס אותו לתוך הצינור עצמו - כך שכתיבת קוד, תיקון באגים ופתיחת Merge Request לא תלויות בכך שמישהו יושב מול המחשב ומריץ פקודה. בדיוק את זה עושה האינטגרציה של Claude Code עם GitLab CI/CD: היא הופכת את ה-@claude בתגובה על issue או על MR לטריגר שמפעיל job בצינור, שמריץ את Claude Code בתוך container מבודד, וברוב המקרים מסיים בפתיחת MR מוכן לבדיקה.

מה זו אינטגרציית Claude Code ל-GitLab CI/CD

האינטגרציה בנויה על גבי Claude Code CLI וה-Agent SDK, מה שאומר שהיא מאפשרת שימוש פרוגרמטי ב-Claude בתוך jobs של CI/CD ובתהליכי אוטומציה מותאמים אישית. חשוב לדעת: זו אינטגרציה שמתוחזקת על ידי GitLab עצמה (התמיכה מתבצעת דרך issue ייעודי במעקב הבאגים של GitLab), והיא כרגע נמצאת בשלב beta - כלומר יכולות ופרטי הקונפיגורציה עשויים להשתנות ככל שהיא מתבגרת.

הרעיון המרכזי הוא orchestration מונע אירועים (event-driven): GitLab מאזין לטריגרים שאתם בוחרים - למשל תגובה שמזכירה @claude ב-issue, ב-MR או בשרשור review - ה-job אוסף את ההקשר מהשרשור ומהריפו, בונה prompt מתוך הקלט הזה, ומריץ את Claude Code. כל השינויים עוברים דרך Merge Request, כך שסוקרים רואים את ה-diff ואישורי ה-branch protection הרגילים שלכם עדיין חלים.

מבחינת ספק המודל, האינטגרציה תומכת ב-abstraction גמיש: אפשר לעבוד מול Claude API הרגיל (SaaS), מול Amazon Bedrock (עם גישה מבוססת IAM ואפשרויות cross-region), או מול Google Cloud's Agent Platform (עם Workload Identity Federation שמותאם לענן של גוגל). זה נותן לארגונים עם דרישות residency או הסכמי רכש קיימים דרך AWS או GCP אפשרות לבחור endpoint אזורי מתאים בלי להתפשר על חוויית העבודה.

כל אינטראקציה רצה בתוך container מבודד עם כללי רשת וקבצים מחמירים - Claude Code אוכף הרשאות שמוגבלות ל-workspace, כך שהכתיבה לקוד מוגבלת לגבולות שהוגדרו מראש. זה חלק ממה שהופך את השימוש בכלי בתוך CI/CD לבטוח יחסית: אין הרצה חופשית על תשתית הייצור, אלא job מבודד שמייצר MR לבדיקה אנושית.

מה Claude יכול לעשות בתוך הצינור

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

יצירה ועדכון של Merge Requests ישירות מתוך תיאורי issue או תגובות עליהם
ניתוח רגרסיות ביצועים והצעת אופטימיזציות קונקרטיות
מימוש פיצ'רים ישירות ב-branch, ואז פתיחת MR באופן אוטומטי
תיקון באגים ורגרסיות שזוהו על ידי בדיקות אוטומטיות או תגובות אנוש
מענה לתגובות המשך בשרשור כדי לבצע איטרציה על שינויים שכבר התבקשו

כלומר, זה לא רק "תריץ בדיקות" - זו יכולת אמיתית לקחת issue שמתאר צורך, ולקבל ממנו branch עם קוד עובד ו-MR פתוח, בלי שמישהו בצוות צריך לפתוח את ה-IDE. באותה מידה, אפשר להשתמש בזה כמנגנון עזרה תוך כדי code review: מזכירים את @claude בדיון על ה-MR עם בקשה קונקרטית - למשל "הצע גישה קונקרטית ל-caching של קריאת ה-API הזו" - וה-job מריץ את הבקשה, מוסיף קוד עם caching מתאים, ומעדכן את ה-MR הקיים.

הקמה צעד אחר צעד

ההקמה המהירה ביותר דורשת שני צעדים בלבד: משתנה CI/CD ממוסך (masked) ו-job אחד בקובץ .gitlab-ci.yml.

שלב 1 - הוספת מפתח ה-API כמשתנה ממוסך

נכנסים ל-Settings ← CI/CD ← Variables, ומוסיפים משתנה בשם ANTHROPIC_API_KEY, מסומן כ-masked (ואם רוצים - גם protected, כדי שיהיה זמין רק ב-branches מוגנים).

שלב 2 - הוספת job לצינור

הדוגמה הבסיסית שמופיעה בתיעוד הרשמי כוללת כמה חלקים: הגדרת stages: [ai] כשלב ייעודי בצינור, שימוש בתמונת node:24-alpine3.21 כבסיס להרצה, כללי הפעלה (rules) לפי מקור הפייפליין - למשל הרצה ידנית דרך הממשק (web) או אירוע Merge Request, שלב before_script שמתקין תלויות בסיסיות (git, curl, bash) ומריץ את סקריפט ההתקנה הרשמי של Claude Code, ולבסוף שלב script שמפעיל שרת MCP ייעודי ל-GitLab (אם קיים) ולאחר מכן קורא לפקודת claude עם ה-prompt, מצב הרשאות ורשימת הכלים המורשים.

כך זה נראה בפועל, שורה אחר שורה בקובץ .gitlab-ci.yml:

stages: [ai] - הגדרת שלב ייעודי בצינור
claude: stage: ai, image: node:24-alpine3.21 - שם ה-job ותמונת ההרצה
rules - הפעלה כש-$CI_PIPELINE_SOURCE == "web" (הרצה ידנית) או כש-$CI_PIPELINE_SOURCE == "merge_request_event"
variables: GIT_STRATEGY: fetch - אסטרטגיית משיכת הקוד
before_script - התקנת git, curl ו-bash, ולאחר מכן הרצת curl -fsSL https://claude.ai/install.sh | bash להתקנת Claude Code
script - הפעלת שרת ה-MCP הייעודי ל-GitLab (אם קיים), ולאחר מכן קריאה לפקודה: claude -p "${AI_FLOW_INPUT}" --permission-mode acceptEdits --allowedTools "Bash Read Edit Write mcp__gitlab" --debug

שימו לב לכמה פרטים חשובים בדוגמה: הדגל --permission-mode acceptEdits קובע ש-Claude Code רשאי לבצע עריכות ללא אישור ידני בכל שלב, והדגל --allowedTools מגדיר בדיוק אילו כלים מותרים - במקרה הזה Bash, קריאה, עריכה, כתיבה, וה-MCP הייעודי של GitLab. המשתנים בסגנון AI_FLOW_INPUT, AI_FLOW_CONTEXT ו-AI_FLOW_EVENT משמשים כשה-job מופעל דרך trigger מבוסס web/API עם payload הקשר - למשל כשתשתית חיצונית קוראת ל-pipeline trigger API בעקבות תגובת @claude.

לאחר שהוספתם את ה-job ואת משתנה ה-API, אפשר לבדוק ידנית דרך CI/CD ← Pipelines, או להפעיל מתוך MR ולתת ל-Claude להציע עדכונים ב-branch (ובמידת הצורך לפתוח MR חדש).

הקמה מלאה לסביבת ייצור

לצוותים שרוצים שליטה רבה יותר, או שצריכים לעבוד מול Amazon Bedrock או Google Cloud's Agent Platform, התיעוד ממליץ על הקמה ידנית שכוללת:

הגדרת גישה לספק המודל הרלוונטי - ANTHROPIC_API_KEY עבור Claude API, תצורת AWS OIDC ותפקיד IAM עבור Amazon Bedrock, או Workload Identity Federation עבור Google Cloud
הוספת פרטי הרשאה לפעולות מול GitLab API: ברירת המחדל היא שימוש ב-CI_JOB_TOKEN, או לחלופין יצירת Project Access Token עם היקף api ואחסונו כמשתנה ממוסך בשם GITLAB_ACCESS_TOKEN
אופציונלית - הפעלת טריגרים מבוססי אזכור: הוספת webhook פרויקטלי ל"Comments (notes)" שמפעיל את pipeline trigger API עם משתנים כמו AI_FLOW_INPUT ו-AI_FLOW_CONTEXT כשמזוהה @claude בתגובה

עבור עבודה מול Amazon Bedrock, הצינור מחליף את ה-OIDC token של GitLab בהרשאות AWS זמניות באמצעות aws sts assume-role-with-web-identity, כך שאין צורך באחסון מפתחות AWS קבועים - רק שני משתנים: AWS_ROLE_TO_ASSUME ו-AWS_REGION. עבור Google Cloud's Agent Platform, ההזדהות נעשית דרך Workload Identity Federation עם המשתנים GCP_WORKLOAD_IDENTITY_PROVIDER, GCP_SERVICE_ACCOUNT ו-CLOUD_ML_REGION, גם כאן בלי הורדת מפתחות service account לדיסק.

אבטחה ומפתחות API - מה חשוב לדעת

הכלל המרכזי שמופיע בתיעוד ברור: לעולם אל תשמרו מפתחות API או פרטי הזדהות ענן בתוך הריפו. כל הפרטים הרגישים - בין אם זה ANTHROPIC_API_KEY ובין אם משתני OIDC של AWS או GCP - אמורים לשבת אך ורק כמשתני CI/CD ממוסכים (masked), ואם צריך - גם מוגנים (protected) כך שהם זמינים רק ב-branches מסוימים.

כמה עקרונות אבטחה נוספים שהתיעוד מדגיש:

העדיפו OIDC ייעודי לספק (AWS או GCP) על פני מפתחות ארוכי טווח, כדי לצמצם את משטח התקיפה
הגבילו הרשאות job ו-egress רשת ככל האפשר - כל job רץ בקונטיינר מבודד עם כללי רשת וקבצים מחמירים
בדקו את ה-MR-ים שנפתחים על ידי Claude בדיוק כפי שהייתם בודקים תרומה של מפתח אחר בצוות - branch protection וכללי אישור רגילים ממשיכים לחול
הרשאות הכתיבה של Claude Code מוגבלות ל-workspace שהוקצה לו, כך שגם אם ה-prompt מנוסח בצורה לא מדויקת, טווח הפעולה מוגבל

שווה גם לשים לב לרשימת ה---allowedTools בכל job בנפרד: זו הדרך לקבוע במפורש אילו כלים (Bash, Read, Edit, Write, ה-MCP של GitLab וכדומה) מותר ל-Claude להשתמש בהם בהרצה הספציפית הזו. job שמיועד רק לסקירת קוד יכול לקבל הרשאות מצומצמות בהרבה מ-job שאמור לממש פיצ'ר שלם.

תרחיש שימוש: צוות פיתוח שמטמיע את זה בפועל

נניח צוות backend בגודל בינוני שעובד ב-GitLab, עם MR-ים רבים שנפתחים מדי שבוע ותור issues שגדל מהר יותר משהצוות מספיק לטפל בו. הצוות מוסיף job בשם claude לשלב ייעודי בצינור, מגדיר ANTHROPIC_API_KEY כמשתנה ממוסך, ומוסיף webhook קטן שמאזין לתגובות (notes) ומפעיל את ה-pipeline trigger API כשמזוהה @claude בתגובה על issue או MR.

מרגע זה, מפתח שנתקל ב-issue פשוט - למשל תיקון TypeError בקומפוננטת dashboard - יכול פשוט לכתוב בתגובה "@claude fix the TypeError in the user dashboard component". הצינור מזהה את האזכור, אוסף את ההקשר מה-issue ומהריפו, ומריץ את Claude Code בתוך container מבודד. Claude מאתר את הבאג, מיישם תיקון, ופותח MR חדש (או מעדכן branch קיים) עם ההסבר לשינוי. חבר צוות אחר סוקר את ה-MR בדיוק כמו כל תרומה אחרת, ומאשר או מבקש שינויים - ואם יש בקשת שינוי בתגובה חדשה, Claude יכול להגיב לה ולבצע איטרציה נוספת על אותו MR.

כדי ש-Claude יעבוד בהתאם למוסכמות הצוות, שווה להשקיע בקובץ CLAUDE.md בשורש הריפו, שמגדיר סטנדרטים לכתיבת קוד, קריטריוני review וכללים ספציפיים לפרויקט - Claude קורא את הקובץ הזה בכל הרצה ופועל לפיו (מומלץ להעמיק בנושא במדריך המלא שלנו על Claude Code). לצוותים גדולים יותר, אפשר גם להריץ jobs נפרדים עם prompts שונים - אחד לסקירה, אחד למימוש, אחד ל-refactoring - כל אחד עם הרשאות ורשימת כלים שמתאימה למשימה שלו, בדומה לעקרונות שמתוארים במדריך שלנו על skills ופקודות מותאמות אישית.

GitLab CI/CD מול GitHub Actions - מה דומה ומה שונה

מי שכבר הכיר את Claude Code דרך אינטגרציית GitHub Actions ירגיש בבית: הרעיון הבסיסי דומה מאוד - אזכור @claude בתגובה על issue או PR מפעיל job שמריץ את ה-CLI בתוך runner, עם מפתח API שמור כמשתנה סודי, ותוצאה שמגיעה בצורת פתיחת בקשת מיזוג או עדכון קיים. גם שם וגם כאן העבודה בנויה סביב אותו Claude Code CLI ו-Agent SDK, כך שההיגיון של prompts, הרשאות כלים (allowedTools) ומצבי הרשאה (permission-mode) דומה מאוד.

ההבדל המרכזי הוא בשכבת ה-orchestration: ב-GitLab, האינטגרציה נבנית ידנית סביב job ב-.gitlab-ci.yml, כללי rules לפי CI_PIPELINE_SOURCE, ולרוב webhook נפרד שמאזין לתגובות ומפעיל את הפייפליין דרך ה-trigger API - כלומר יש כאן יותר "הרכבה ידנית" של הרכיבים בהשוואה לאפליקציה מותקנת מראש. הזהות מול GitLab עצמו (פתיחת MR, כתיבת תגובות) נעשית דרך CI_JOB_TOKEN או Project Access Token עם היקף api. גם ה-provider abstraction בולט מאוד באינטגרציית GitLab: יש תמיכה מובנית ומתועדת בשלושה נתיבים - Claude API, Amazon Bedrock ו-Google Cloud's Agent Platform - עם דוגמאות OIDC/WIF מלאות לכל אחד, מה שמתאים לארגונים עם דרישות residency או הסכמי רכש קיימים.

חשוב גם לזכור שהאינטגרציה הזו מתוחזקת ונתמכת על ידי GitLab (ולא ישירות על ידי Anthropic), והיא נמצאת כרגע בשלב beta רשמי - כך שסביר לצפות לשינויים בפרטי הקונפיגורציה ובדגלים הנתמכים ככל שהיא מתפתחת. אם אתם כבר מריצים אוטומציות דומות סביב GitHub, כדאי גם להציץ במדריך שלנו על אוטומציה עם GitHub API ו-CI/CD כדי להשוות גישות.

עלויות וטיפים לאופטימיזציה

שני מקורות עלות עיקריים נכנסים לתמונה כשמריצים את Claude Code בתוך GitLab CI/CD:

זמן ריצה של GitLab Runner - כל הרצה של Claude צורכת דקות compute מה-runner שלכם, בהתאם לתוכנית ה-billing של GitLab
עלויות API - כל אינטראקציה עם Claude צורכת טוקנים לפי גודל ה-prompt והתשובה, וכמות הטוקנים משתנה לפי מורכבות המשימה וגודל הקודבייס

כמה טיפים מהתיעוד לצמצום עלויות: להשתמש בפקודות @claude ממוקדות כדי לצמצם סבבי עבודה מיותרים, להגדיר ערכי max_turns וזמני timeout סבירים ל-job כדי למנוע הרצות שנמשכות יותר מדי, ולהגביל concurrency כדי לשלוט בכמות ההרצות המקבילות. שווה גם לשמור על CLAUDE.md ממוקד ותמציתי, ולתת תיאורי issue ו-MR ברורים - כך יורד מספר האיטרציות הדרושות עד לתוצאה טובה.

שאלות נפוצות

האם צריך התקנה נפרדת של Claude Code על כל runner?

לא צריך התקנה קבועה מראש - ה-job עצמו מתקין את Claude Code בכל הרצה, באמצעות סקריפט ההתקנה הרשמי (curl -fsSL https://claude.ai/install.sh | bash) בשלב ה-before_script. כך אין תלות בתמונת runner מותאמת אישית, אבל כדאי לזכור שההתקנה עצמה מוסיפה זמן ריצה לכל job.

איזה מפתח API צריך, ואיפה שומרים אותו?

עבור עבודה מול Claude API הרגיל נדרש ANTHROPIC_API_KEY, שאותו שומרים כמשתנה CI/CD ממוסך (masked) ב-Settings ← CI/CD ← Variables, ואפשר גם להגדיר כ-protected. עבור Amazon Bedrock או Google Cloud's Agent Platform לא נדרש מפתח API קבוע - במקום זאת עובדים מול OIDC או Workload Identity Federation עם משתני תפקיד וייעוד אזור.

האם Claude יכול לפתוח MR באופן עצמאי, בלי אישור ידני בכל שלב?

כן - כשה-job מוגדר עם --permission-mode acceptEdits, Claude Code מבצע את העריכות בלי לעצור לאישור בכל צעד, אבל השינוי עצמו תמיד עובר דרך פתיחת Merge Request. זה אומר שאין דילוג על תהליך ה-review האנושי - הוא רק זז לשלב ה-MR במקום לשלב הכתיבה השוטפת.

מה קורה אם Claude לא מגיב לתגובת @claude?

לפי הדרכת פתרון התקלות הרשמית, כדאי לבדוק כמה דברים: שהצינור אכן מופעל (ידנית, דרך אירוע MR, או דרך listener/webhook לאזכורים), שמשתני ה-CI/CD כמו ANTHROPIC_API_KEY או הגדרות ספק הענן קיימים ולא חסרים, ושהתגובה אכן מכילה @claude (ולא /claude) עם טריגר האזכור מוגדר נכון.

מה עושים אם ה-job לא מצליח לכתוב תגובות או לפתוח MR?

יש לוודא של-CI_JOB_TOKEN יש הרשאות מספיקות בפרויקט, או להשתמש ב-Project Access Token עם היקף api במקומו. בנוסף כדאי לבדוק שהכלי mcp__gitlab אכן מופיע ברשימת --allowedTools של ה-job, ושה-job רץ בהקשר של ה-MR הרלוונטי או מקבל מספיק הקשר דרך משתני AI_FLOW.

האם זו יכולת יציבה שאפשר לסמוך עליה בסביבת ייצור?

האינטגרציה מסומנת כרגע כ-beta רשמית מטעם GitLab, כך שיכולות ופרטי קונפיגורציה עשויים להשתנות. זה לא אומר שאסור להשתמש בה בייצור - אבל כדאי לגשת אליה כמו לכל כלי בשלב beta: להתחיל בהיקף מוגבל (job אחד, permissions מצומצמות), לעקוב אחרי עדכוני התיעוד, ולשמור על review אנושי צמוד ל-MR-ים שנפתחים.

הטמעת Claude Code בתוך GitLab CI/CD היא לא פרויקט של שבועות - זה בעיקרון job אחד וקובץ CLAUDE.md מסודר, אבל יש כמה החלטות (בחירת ספק מודל, היקף הרשאות, טריגרים) שכדאי לקבל נכון מההתחלה כדי שזה יעבוד בבטחה וביעילות בסביבה שלכם. אם אתם רוצים ליווי בהקמת האינטגרציה הזו בריפו של הצוות שלכם, או פשוט לשמוע איך זה עובד עם ה-stack הספציפי שלכם, אנחנו כאן - מוזמנים לפנות אלינו בוואטסאפ

תגיות: Claude Code · GitLab CI/CD · gitlab-ci.yml · אוטומציה · Merge Request · DevOps · AI Agent

← חזרה לבלוג · צור קשר