ברגע שפרויקט רץ מקומית, ארבע פקודות מעבירות אותו לאתר חי באחסון של Zinn Digital®: התחברות, קישור הפרויקט לסלוט אחסון, קריאת בדיקת הטרום-טיסה (pre-flight) וביצוע push. מאמר זה עובר על כל אחת מהן, מה היא מדפיסה, והפקודות שתזדקקו להן לאחר מכן — פריסות מחדש, היסטוריית פריסות ויומני בנייה.
התחברות באמצעות מפתח API
צרו מפתח בלוח הבקרה תחת הגדרות ← מפתחות API, ולאחר מכן:
zinnector login
המפתח מוקלד בהודעת בקשה — הוא לעולם אינו מתקבל בשורת הפקודה, כך שהוא אינו יכול להגיע להיסטוריית ה-shell או לרשימת תהליכים. ב-CI, הזרימו אותו ב-pipe: echo "$ZINN_API_KEY" | zinnector login --profile ci, או הגדירו את ZINNECTOR_TOKEN ודלגו על login לחלוטין. המפתח מאומת לפני שמירתו, ונשמר עם הרשאת קובץ 600. הפקודה zinnector whoami --scopes מציגה לאיזה ארגון אתם מחוברים ואילו הרשאות המפתח נושא; מפתח sandbox מתויג ככזה.
קישור הפרויקט לסלוט
zinnector link # pick a site from a list
zinnector link example.com --repo acme/site --branch main
הפקודה link כותבת את מזהה האתר לתוך zinnector.json, ולמעט אם תעבירו את --no-repo, מחברת את ה-remote של ה-git של הפרויקט לאתר בפלטפורמה כך שפעולת push תפרוס אותו. בצעו commit ל-zinnector.json: עמית שישכפל את המאגר יוכל לפרוס לאותו מקום מבלי שיצטרכו להדריך אותו. הוא אינו מכיל סודות.
קריאת בדיקת הטרום-טיסה
zinnector check
זוהי הפקודה שלשמה ה-CLI קיים. היא משווה את הפרויקט שלכם מול הסלוט שאליו הוא עומד להיפרס ומדפיסה כל אי-התאמה — וכל השוואה שהיא לא הצליחה לבצע:
- גרסת PHP, כאשר פער בגרסה הראשית (major) מדורג כ-גבוה מכיוון שהוא בוודאות שובר אתרים, ופער בגרסה משנית מדורג נמוך יותר, משום שדירוג כל דבר כקריטי מרגיל אנשים להתעלם מהאזהרה.
- האם הסלוט יכול לעבור לגרסה שעליה בניתם, האם גרסת ה-PHP של הסלוט עברה את סוף התמיכה (end of life), והאם המכונה החילה את הגרסה בפועל או שרק קיבלה הוראה לעשות זאת.
- הגודל ומספר הקבצים של הפרויקט שלכם מול מרווח הדיסק וה-inodes שנותר בפועל בסלוט — עץ קבצים של WordPress עלול להגיע למגבלת הקבצים שלו הרבה לפני שהוא ממצה את מכסת הדיסק.
- גרסאות ה-WordPress בכל צד, האם הסלוט סיים את ההקצאה (provisioning), והאם מאגר מקושר לצורך ביצוע push.
היא מזהירה; היא לעולם אינה חוסמת. ניתן לעקוף כל ממצא בעזרת zinnector push --force, מכיוון שאתם יודעים על האתר שלכם דברים שהבודק אינו יודע. השוואה שלא ניתן היה לבצע מדווחת כ-לא ידועה, לעולם לא כהצלחה, והסיכום תמיד מציין כמה כאלה היו. כברירת מחדל גרסת ה-PHP המקומית היא זו שמוצהרת ב-zinnector.json; השימוש ב---probe מפעיל את סביבת הריצה המקומית ומודד אותה במקום זאת. הדגל --strict גורם ליציאה בקוד שאינו אפס גם במקרה של ערכים לא ידועים, וזה מה ששער CI דורש.
ביצוע Push
zinnector push
הפקודה push מריצה את בדיקת הטרום-טיסה, מבצעת push ל-commits שלכם, מפעילה את הפריסה ועוקבת אחריה עד להשלמתה, תוך הדפסת הסטטוס הסופי וה-commit שנפרס. הדגל --dry-run מבצע הכל למעט הפריסה בפועל; --no-wait מפעיל אותה ויוצא; --no-git פורס את מה שכבר נמצא בפלטפורמה מבלי לבצע push. אם ה-commit שנפרס אינו זה שזה עתה עבר push, הפקודה תציין זאת.
כאשר משהו משתבש
zinnector deploys example.com # deploy history — status, commit, trigger, message
zinnector logs example.com --build # the build log of the most recent deploy
zinnector logs example.com --error # the site's error log
zinnector deploy example.com # redeploy what the platform already has
zinnector ai "why is my deploy failing?"
הפקודה zinnector ai רצה על גבי הפלטפורמה מול החשבון שלכם, כך שהיא יכולה לראות את אותה היסטוריית פריסות ויומנים. מתוך פרויקט היא שולחת את מבנה הפרויקט — שמות תיקיות, גרסאות ומזהה האתר — ולעולם לא את תוכן הקבצים.
נושאים קשורים