CoRoidמפעל התוכנה שלך של AI
תיעוד

אירועי פריסה והגדרת CI

חברו את GitHub Actions, GitLab CI/CD או מערכת CI אחרת להיסטוריית הפריסות של Release.

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

CoRoid

ה-CI/CD שלכם

סביבה

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

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

פעולות GitHub ו-GitLab CI/CD

אם ברצונכם שהכפתור פריסה ל… בעמוד הגרסאות יופיע, בחרו CoRoid מפעיל תהליך עבודה של GitHub Actions או CoRoid מפעיל צינור ניהול פרויקטים של GitLab CI/CD בהגדרות צינור הפריסה של הסביבה. הזינו את שם משימת הפריסה המדויק, את הענף או התווית, ואת שם קובץ התהליך של GitHub כשזה רלוונטי. הענף חייב להצביע על קובץ התרגום בזמן הבקשה, אלא אם תהליך ה-GitHub מגדיר coroid_artifact_sha קלט (ראו למטה). תהליך ה-GitHub מקבל coroid_release_id, coroid_attempt_id, coroid_commit_sha, ו coroid_environment קלטים, בנוסף coroid_version, coroid_build_number, coroid_release_name ו coroid_artifact_sha כאשר תהליך העבודה מגדיר אותם. GitLab מקבל את המשתנים המקבילים באותיות גדולות COROID_* . השתמשו בערכים אלה כדי לבצע פריסה ולדווח על ה-SHA והניסיון המדויקים.

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

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

  • coroid_expected_revision הוא הקובץ שבו הסביבה פעלה בזמן בקשת הפריסה. השוו אותו עם מה שהסביבה מפעילה לפני הפריסה. אם יש הבדל, מישהו ביצע פריסה בינתיים, ולכן יש לעצור ללא ביצוע פריסה.
  • coroid_rollback הוא true כאשר הפעולה מבצעת חזרה של הסביבה. יש להקצות לפעולות כאלה קבוצת סימולטניות משלהן, כך שחזרה לעולם לא תחכה אחרי פריסה. לפני חזרה, CoRoid מבטל פריסה שעדיין פועלת וממתין עד שתיפסק. אם היא אינה נפסקת בזמן, שום דבר לא יוחזר ובעלים ומנהלים יקבלו הודעה.

GitLab מקבל אותם כ- COROID_EXPECTED_REVISION ו- COROID_ROLLBACK. הכניסו את הגרסה לבנייה שלכם מציג כיצד לסמן את הגרסה בבנייה.

יש לקרוא לכל פעולה על פי הניסיון שלה, כך שCoRoid יוכל למצוא פעולה שאותה לא שמע עליה כשהחלה. ב-GitHub Actions, יש להגדיר run-name לטקסט שמכיל coroid_attempt_id. ב-GitLab, הגדירו workflow:name לטקסט שמכיל $COROID_ATTEMPT_ID:

# GitHub Actions
run-name: ${{ inputs.coroid_attempt_id && format('Deploy (attempt {0})', inputs.coroid_attempt_id) || 'Deploy' }}

# GitLab CI/CD
workflow:
  name: 'Deploy $COROID_ATTEMPT_ID'

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

שמרו את אסימון ההחזרה של הסביבה כנתונים חשאיים ב-GitHub Actions או כמשתנים מוסתרים ב-GitLab CI/CD. שלחו אירוע running כאשר משימת הפריסה מתחילה ואירוע סופי succeeded, failed, או cancelled אירוע כאשר הוא מסתיים. CoRoid בודק את הפעולה של הספק, ההתחייבות ומשימת השם לפני שמקבל הצלחה עבור צינור ניהול פרויקטים מוגדר. כתובת ה-URL של הפעולה של הספק נשארת המקום לבדיקת יומני רישום.

תהליך עבודה של GitHub שפועל מקובץ אחד ומבצע פריסה של אחר, למשל כזה עם ref קלט לצורך פריסת קובץ ישן או חזרה לקדמות, חייב לציין איזה קובץ הוא מפריס. יצרו פריסת GitHub עבור הקובץ שנפרס בסביבה, ותנו לסטטוס הסופי שלו success סטטוס של log_url שמקשר להרצת תהליך העבודה. לאחר מכן, אפליקציית GitHub זקוקה להרשאת המאגר . ה. ה תהליך עבודה לייצור של CoRoid כולל דוגמה מעשית ל-GitHub Actions; התאימו את שמות הסודות ואת המשימה למאגר שלכם.

קריאה חוזרת כללית מ-CI

צינור חיצוני יכול לשלוח את אותם אירועים בלי להפעיל שליחה. בצעו אימות באמצעות אסימון bearer המוגבל לסביבה. נקודת הקצה מקבלת JSON במבנה הגרסה הבא:

POST /api/v1/release-deployment-events
Authorization: Bearer <environment-callback-token>
Content-Type: application/json
{
  "schemaVersion": 1,
  "eventId": "ci:run-812:production:succeeded",
  "providerRunId": "run-812",
  "projectId": "<project-uuid>",
  "environmentKey": "production",
  "repository": "owner/repository",
  "commitSha": "0123456789abcdef0123456789abcdef01234567",
  "status": "succeeded",
  "occurredAt": "2026-09-24T12:00:00Z",
  "runUrl": "https://ci.example.com/runs/812"
}

ו- releaseId וגם attemptId בעת דיווח על פעולה שביקשה CoRoid. יש להוסיף version וגם buildNumber כדי לרשום מה פורסת. עבור פרויקט המאוחסן ב-CoRoid, repository יכול להסביר תהליך כושל. השתמשו ב- failureReason יכול להסביר הרצה שנכשלה. השתמשו ב- queued, running, succeeded, failed, cancelled, או rolled_back עבור statusדוח rolled_back כאשר הריצה שדרגה את הסביבה ואז החזירה את הגרסה הקודמת מכיוון שהגרסה החדשה נכשלה. יש לשמור על אחת providerRunId לאורך כל הריצה ולהקצות לכל מעבר מצב מזהה ייחודי eventId. ניסיון חוזר של אותו אירוע צריך לשמור על אותו מזהה; ריצת CI חדשה דורשת מזהה ריצה חדש. ריצה מחדש של GitHub שומרת על ה attemptId ומדווחת על ניסיון הריצה שלה ב providerRunId (<run id>-<run attempt>). אם הוא מפעיל מחדש את הפריסה האחרונה של הסביבה, CoRoid יפעל לפי אותה פריסה. אחרת, CoRoid רושם זאת כפריסה נפרדת שצפה בה. חותמת הזמן של האירוע חייבת להיות עדכנית. CoRoid בודק מאגר, סביבה, התחייבות, טווח אישורים ומצב סופי לפני יישום; אירועים סותרים נשמרים לבדיקה. פריסה תקפה ללא שחרור מוכן יכולה ליצור שחרור שנצפה, הנבדל בבירור ממועמד שאושר מראש. הוא לוקח את version האירוע מדווח, או כאשר CoRoid מקצה גרסאות לפרויקט, את הבאה בתור.

גרסה 2 של האירוע ("schemaVersion": 2) גם מדווחת על שתי הזהויות של פריסה: מה שנפרס ומה שביצע את הפריסה. artifact מכילה את הקומיט שנפרס, שחייב להיות שווה ל commitSha, ולתמצית של כל תמונה. workflow מכילה את הקומיט שממנו התחילה הריצה, ובאופן אופציונלי את ה-ref שלו:

{
  "schemaVersion": 2,
  "commitSha": "0123456789abcdef0123456789abcdef01234567",
  "artifact": {
    "sha": "0123456789abcdef0123456789abcdef01234567",
    "images": [{ "name": "app", "digest": "sha256:…" }]
  },
  "workflow": {
    "sha": "89abcdef0123456789abcdef0123456789abcdef",
    "ref": "owner/repository/.github/workflows/deploy.yml@refs/heads/main"
  }
}

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

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