اتصال میزبان کد
Control Center با سه میزبان کد کار می‌کند که در سراسر برنامه forge نامیده می‌شوند: GitHub، GitLab و Bitbucket Cloud. هیچ‌کدام پیش‌فرض نیست. یکی را متصل کنید و همه‌چیز کار می‌کند؛ چند تا را متصل کنید و یک فضای کاری می‌تواند مخزن‌های همهٔ آن‌ها را هم‌زمان در خود جای دهد.
میزبان کد ویژگی هر مخزن است و هنگام ثبت آن، از ریموت origin آن خوانده می‌شود. هرگز آن را انتخاب نمی‌کنید و هیچ تنظیمی در سطح فضای کاری نیست که بتوانید اشتباه کنید.
اتصال یک میزبان کد
بخش با عنوان “اتصال یک میزبان کد”- تنظیمات → فضای کاری → نمایه و هویت را باز کنید (
/settings/workspace/profile). - کارت میزبانی کد را پیدا کنید. هر میزبان کد پشتیبانی‌شده در آن فهرست شده است، متصل یا نامتصل.
- اگر آن ردیف چنین گزینه‌ای دارد، ورود با … را بزنید، وگرنه افزودن توکن را بزنید و یکی را جای‌گذاری کنید.
ورود برای میزبانی نمایش داده می‌شود که سرور شما برایش برنامه‌ای ثبت کرده است — امروز این میزبان GitHub است، از طریق جریان دستگاه (به ایجاد GitHub App نگاه کنید). هر چیز دیگری یک توکن جای‌گذاری‌شده است، که همان گزینهٔ صادقانه است، نه دکمه‌ای که نمی‌تواند به سرانجام برسد.
در هر دو حالت، اعتبارنامه از شماست و روی سرور می‌ماند و با شناسهٔ کاربری شما کلید می‌خورد: هیچ توکنی روی دستگاهی که آن را در آن وارد کرده‌اید ذخیره نمی‌شود، هر دستگاهی که از آن وارد می‌شوید از همان یکی استفاده می‌کند و هیچ عضو دیگری نمی‌تواند آن را بخواند. از درخواست بعدی اثر می‌کند — چیزی برای راه‌اندازی مجدد نیست و قطع اتصال، ارسال آن را بلافاصله متوقف می‌کند.
هر ردیف می‌گوید اعتبارنامه‌اش از کجا آمده است، چون همین تفاوت میان «توکن من کار نمی‌کند» و «توکن دیگری پاسخ می‌دهد» است:
| زیرنویس | معنا |
|---|---|
وارد شده به‌عنوان octocat |
اعتبارنامهٔ خودتان به کار می‌رود |
وارد شده به‌عنوان octocat · از طریق برنامهٔ این سرور |
هویت برنامهٔ سرور پاسخ می‌دهد — شما وارد نشده‌اید |
وارد شده به‌عنوان octocat · از محیط |
یک متغیر محیطی سرور پاسخ می‌دهد، نه اعتبارنامهٔ شما |
متصل نیست |
برای این میزبان کد اعتبارنامه‌ای ندارید |
هر میزبان کد چه توکنی می‌خواهد
بخش با عنوان “هر میزبان کد چه توکنی می‌خواهد”| میزبان کد | توکن | کجا آن را بسازید |
|---|---|---|
| GitHub | Classic: repo و read:org. Fine-grained: Contents + Pull requests (read/write), Checks + Actions (read) |
github.com → Settings → Developer settings → Tokens |
| GitLab | یک توکن دسترسی شخصی با api |
gitlab.com → User settings → Access tokens |
| Bitbucket | یک توکن API از Atlassian، به‌همراه ایمیل حساب شما | id.atlassian.com → Security → API tokens |
Bitbucket با ایمیل حساب شما به‌عنوان نام کاربری و توکن به‌عنوان گذرواژه احراز هویت می‌کند. BITBUCKET_EMAIL را در محیط سرور تنظیم کنید تا بداند کدام ایمیل را با توکن جفت کند.
یا از متغیرهای محیطی استفاده کنید
بخش با عنوان “یا از متغیرهای محیطی استفاده کنید”برای نصب بدون رابط یا CI، سرور این‌ها را می‌خواند:
- GitHub —
GITHUB_TOKEN، سپسGH_TOKEN - GitLab —
GITLAB_TOKEN، سپسCI_JOB_TOKEN - Bitbucket —
BITBUCKET_API_TOKEN، سپسBITBUCKET_TOKEN(به‌همراهBITBUCKET_EMAIL)
این‌ها اعتبارنامهٔ سروراند، نه شما؛ و این تفاوت تعیین‌کننده است: درخواستی که به نیابت از شما فرستاده می‌شود فقط از اعتبارنامهٔ خود شما استفاده می‌کند و از چیز دیگری نه، پس محیط هرگز بی‌صدا جای شما را نمی‌گیرد. کاری که هیچ انسانی پشت آن نیست — وبهوک‌ها، نظرسنجی PR، همگام‌سازی تیکت — نخست هویت برنامهٔ سرور را حل می‌کند، سپس اعتبارنامهٔ مالک سرور را، و بعد محیط را. این ترتیب ثابت است تا «وارد شدم و هیچ‌چیز عوض نشد» هرگز نتیجهٔ پشتیبانی‌شده‌ای نباشد.
روی هر میزبان کد، شما آدم دیگری هستید
بخش با عنوان “روی هر میزبان کد، شما آدم دیگری هستید”همان انسان روی GitHub octocat است و روی GitLab چیزی کاملاً دیگر. Control Center هویت شما را به تفکیک هر میزبان کد حل می‌کند و برای هر مخزن همان درست را به کار می‌برد؛ همین است که «نیاز به بازبینی من» را، «ساختهٔ من» را و «شما این را تأیید کردید» را در یک فضای کاری مخلوط درست می‌کند.
اگر هویت یک میزبان کد حل نشده باشد، مخزن‌هایش به‌جای اینکه با همه‌چیز مطابقت کنند، هیچ چیزی به صندوق ورودی نمی‌دهند. صندوق ورودی همین را می‌گوید، نه اینکه ادعا کند همه‌چیز را رسیدگی کرده‌اید.
یک صندوق ورودی، همهٔ میزبان‌های کد
بخش با عنوان “یک صندوق ورودی، همهٔ میزبان‌های کد”صندوق ورودی و صف PR روی هر میزبانی که در فضای کاری حاضر است پخش می‌شوند و نتایج را در یک جریان یکی می‌کنند — یک pull request از GitHub و یک pull request از Bitbucket کنار هم می‌نشینند، به ترتیب زمان، نه گروه‌بندی‌شده بر پایهٔ فروشنده.
خطاها جدا از هم‌اند. میزبانی که از کار افتاده، با محدودیت نرخ محدود شده یا متصل نشده باشد هیچ چیزی نمی‌دهد و بقیه را دست‌نخورده می‌گذارد؛ هرگز کل صندوق ورودی را خالی نمی‌کند. مخزن‌های خودش تا زمانی که بهبود یابد، آخرین وضعیت شناخته‌شده‌شان را نشان می‌دهند.
هر میزبان کد چه کارهایی می‌تواند بکند
بخش با عنوان “هر میزبان کد چه کارهایی می‌تواند بکند”هر میزبان کدی از حلقهٔ اصلی پشتیبانی می‌کند: فهرست‌کردن و باز کردن pull requestها، خواندن diffها، نظر دادن به‌صورت درون‌خطی و در سطح بالا، بازبینی، ادغام و بستن. فراتر از آن، آن‌ها واقعاً با هم تفاوت دارند و Control Center آنچه را یک میزبان کد نمی‌تواند انجام دهد پنهان می‌کند، نه اینکه کنترلی نشان دهد که بی‌صدا شکست می‌خورد.
| توانایی | GitHub | GitLab | Bitbucket |
|---|---|---|---|
| بازبینی‌های دسته‌ای (در انتظار) | ✓ | ✓ | — |
| درخواست تغییر | ✓ | ✓ | ✓ |
| وضعیت «دیده‌شده» به تفکیک فایل، همگام‌شده | ✓ | — | — |
| واکنش‌های ایموجی | ✓ | ✓ | — |
| بازبین‌های تیم / گروه | ✓ | ✓ | — |
| بازبین‌های پیشنهادی | ✓ | — | ✓ |
| نتایج CI روی یک PR | ✓ | ✓ | ✓ |
| کندوکاو در گام‌ها/لاگ‌های یک کار CI | ✓ | ✓ | — |
| pull requestهای پشته‌ای | ✓ | — | — |
| قالب‌های توضیح PR | ✓ | ✓ | — |
| نظرسنجی اعلان‌ها | ✓ | — | — |
| نمایه‌های کاربری غنی | ✓ | ✓ | — |
| ارجاع head برای PR در سمت سرور | ✓ | ✓ | — |
آن‌جا که توانایی‌ای وجود ندارد، قابلیت صادقانه تنزل می‌کند:
- وضعیت دیده‌شده همچنان کار می‌کند، اما فقط روی دستگاهی که آن را رویش تنظیم کرده‌اید.
- بازبینی‌های دسته‌ای در Bitbucket نظر به نظر ارسال می‌شوند، پس بازبین‌ها آن‌ها را یکی‌یکی می‌بینند، نه یک‌جا.
- نبود ارجاع head برای PR در Bitbucket یعنی چک‌اوت کردن یک pull request شاخهٔ مبدأ آن را با نام می‌گیرد، که پس از حذف آن شاخه شکست می‌خورد.
واژگان
بخش با عنوان “واژگان”GitLab به یک pull request می‌گوید merge request. Control Center در سراسر مدل خودش «pull request» می‌گوید و آن‌جا که دربارهٔ خود یک میزبان کد حرف می‌زند، از اسم خود همان میزبان استفاده می‌کند.
عیب‌یابی
بخش با عنوان “عیب‌یابی”فهرست PR خالی است و می‌گوید یک میزبان کد متصل نیست
بخش با عنوان “فهرست PR خالی است و می‌گوید یک میزبان کد متصل نیست”برای آن میزبان کد اعتبارنامه‌ای ندارید. در تنظیمات → فضای کاری → نمایه و هویت → میزبانی کد وارد شوید یا توکنی جای‌گذاری کنید. مخزن‌های دیگر میزبان‌ها دست‌نخورده می‌مانند.
یک میزبان کد را متصل کردم اما مخزن‌هایش هنوز چیزی نشان نمی‌دهند
بخش با عنوان “یک میزبان کد را متصل کردم اما مخزن‌هایش هنوز چیزی نشان نمی‌دهند”زیرنویس آن ردیف را بررسی کنید. اگر «از طریق برنامهٔ این سرور» یا «از محیط» نوشته باشد، اعتبارنامه‌ای غیر از آنچه انتظار داشتید پاسخ می‌دهد — اعتبارنامهٔ خودتان برای هر چیزی که بخواهید برنده است، پس اگر جز این نوشته باشد، مال شما ذخیره نشده است.
یک مخزن ثبت نمی‌شود
بخش با عنوان “یک مخزن ثبت نمی‌شود”ثبت به هر سه مورد نیاز دارد: مسیر داخل یک worktree گیت باشد، ریموت origin داشته باشد و آن ریموت به github.com، gitlab.com یا bitbucket.org اشاره کند. افزودن مخزن به فضای کاری را ببینید.
پس از استفادهٔ سنگین، همه‌چیز مدتی از کار می‌افتد
بخش با عنوان “پس از استفادهٔ سنگین، همه‌چیز مدتی از کار می‌افتد”این همان قطع‌کنندهٔ مدار محدودیت نرخ است. میزبانی که محدودیت اصلی‌اش را اعلام کند باعث می‌شود کلاینت درخواست‌های بعدی را محلی و بدون تماس شبکه‌ای رد کند تا آن بازه بگذرد — پس طوفان تلاش‌های مجدد نمی‌تواند محدودیت را عمیق‌تر کند. خطاهای گذرا با عقب‌نشینی نمایی دوباره تلاش می‌شوند.