เชื่อมต่อโฮสต์โค้ด

Control Center ทำงานกับโฮสต์โค้ดสามเจ้า ซึ่งแอปนี้เรียกว่า ฟอร์จ ตลอดทั้งแอป: GitHub, GitLab และ Bitbucket Cloud ไม่มีเจ้าใดเป็นค่าเริ่มต้น เชื่อมต่อเจ้าเดียวแล้วทุกอย่างก็ทำงาน เชื่อมหลายเจ้าและเวิร์กสเปซเดียวก็เก็บรีโปจากทุกเจ้าได้พร้อมกัน

ฟอร์จเป็นคุณสมบัติของแต่ละรีโป โดยอ่านจาก remote origin ของมันตอนที่คุณลงทะเบียน คุณไม่ต้องเลือกเอง และไม่มีตั้งค่าใดต่อเวิร์กสเปซที่จะตั้งผิดได้

เชื่อมต่อฟอร์จ

เปิด การตั้งค่า → เวิร์กสเปซ → โปรไฟล์และตัวตน (/settings/workspace/profile)
หาการ์ด โฮสต์โค้ด ฟอร์จที่รองรับทั้งหมดจะอยู่ในรายการ ไม่ว่าเชื่อมต่อแล้วหรือไม่
กด ลงชื่อเข้าใช้ด้วย … หากแถวนั้นมีให้ หรือกด เพิ่มโทเค็น แล้ววางโทเค็นลงไป

ลงชื่อเข้าใช้ จะปรากฏสำหรับฟอร์จที่เซิร์ฟเวอร์ของคุณมีแอปลงทะเบียนไว้ — ปัจจุบันคือ GitHub ผ่าน device flow (ดู สร้าง GitHub App) นอกนั้นคือการวางโทเค็น ซึ่งเป็นการสื่อความที่ตรงไปตรงมา แทนที่จะเป็นปุ่มที่กดแล้วทำอะไรไม่ได้

ไม่ว่าจะทางไหน ข้อมูลรับรองเป็นของคุณและอยู่บนเซิร์ฟเวอร์ โดยใช้ user id ของคุณเป็นคีย์: ไม่มีโทเค็นถูกเก็บไว้บนเครื่องที่คุณพิมพ์มันลงไป ทุกอุปกรณ์ที่คุณลงชื่อเข้าใช้ใช้โทเค็นเดียวกัน และสมาชิกคนอื่นอ่านมันไม่ได้ มันมีผลตั้งแต่คำขอถัดไป — ไม่มีอะไรต้องรีสตาร์ต และการยกเลิกการเชื่อมต่อจะหยุดส่งมันทันที

แต่ละแถวบอกว่าข้อมูลรับรองของมันมาจากไหน เพราะนั่นคือความต่างระหว่าง “โทเค็นของฉันใช้ไม่ได้” กับ “มีโทเค็นอื่นเป็นคนตอบ”:

คำบรรยายใต้ชื่อ	ความหมาย
`ลงชื่อเข้าใช้เป็น octocat`	ข้อมูลรับรองของคุณเองเป็นตัวที่ถูกใช้
`ลงชื่อเข้าใช้เป็น octocat · ผ่านแอปของเซิร์ฟเวอร์นี้`	ตัวตนแอปของเซิร์ฟเวอร์เป็นคนตอบ — คุณยังไม่ได้ลงชื่อเข้าใช้
`ลงชื่อเข้าใช้เป็น octocat · จากสภาพแวดล้อม`	ตัวแปรสภาพแวดล้อมของเซิร์ฟเวอร์เป็นคนตอบ ไม่ใช่ข้อมูลรับรองของคุณ
`ยังไม่เชื่อมต่อ`	คุณไม่มีข้อมูลรับรองสำหรับฟอร์จนี้

แต่ละฟอร์จต้องการโทเค็นแบบไหน

ฟอร์จ	โทเค็น	สร้างได้ที่ไหน
GitHub	แบบคลาสสิก: `repo` และ `read:org` แบบละเอียด: Contents + Pull requests (อ่านและเขียน), Checks + Actions (อ่าน)	github.com → Settings → Developer settings → Tokens
GitLab	โทเค็นการเข้าถึงส่วนบุคคลที่มี `api`	gitlab.com → User settings → Access tokens
Bitbucket	API token ของ Atlassian บวกอีเมลบัญชีของคุณ	id.atlassian.com → Security → API tokens

Bitbucket ยืนยันตัวตนด้วยอีเมลบัญชีของคุณเป็นชื่อผู้ใช้ และใช้โทเค็นเป็นรหัสผ่าน ตั้ง BITBUCKET_EMAIL ในสภาพแวดล้อมของเซิร์ฟเวอร์ เพื่อให้รู้ว่าต้องจับคู่อีเมลใดกับโทเค็น

หรือใช้สภาพแวดล้อม

สำหรับการติดตั้งแบบ headless หรือ CI เซิร์ฟเวอร์จะอ่านค่าเหล่านี้:

GitHub — GITHUB_TOKEN แล้วจึง GH_TOKEN
GitLab — GITLAB_TOKEN แล้วจึง CI_JOB_TOKEN
Bitbucket — BITBUCKET_API_TOKEN แล้วจึง BITBUCKET_TOKEN (พร้อม BITBUCKET_EMAIL)

ค่าเหล่านี้เป็นข้อมูลรับรองของเซิร์ฟเวอร์ ไม่ใช่ของคุณ และความต่างข้อนี้สำคัญมาก: คำขอที่ทำในนามของคุณใช้ข้อมูลรับรองของคุณและไม่มีอะไรอื่น สภาพแวดล้อมจึงไม่เคยแอบทำหน้าที่แทนคุณ งานที่ไม่มีมนุษย์อยู่เบื้องหลัง — webhook, การโพลล์ PR, การซิงค์ตั๋วงาน — จะใช้ตัวตนแอปของเซิร์ฟเวอร์ก่อน จากนั้นข้อมูลรับรองของเจ้าของเซิร์ฟเวอร์ แล้วจึงสภาพแวดล้อม ลำดับนี้ตายตัว เพื่อให้ “ฉันลงชื่อเข้าใช้แล้วแต่ไม่มีอะไรเปลี่ยน” ไม่ใช่ผลลัพธ์ที่รองรับ

คุณเป็นคนละคนกันในแต่ละฟอร์จ

มนุษย์คนเดียวกันเป็น octocat บน GitHub และเป็นชื่ออื่นโดยสิ้นเชิงบน GitLab Control Center แยกแยะตัวตนของคุณตามฟอร์จ และใช้ตัวตนที่ถูกต้องกับแต่ละรีโป นี่คือสิ่งที่ทำให้ “ต้องให้ฉันรีวิว” “สร้างโดยฉัน” และ “คุณอนุมัติสิ่งนี้” ถูกต้องในเวิร์กสเปซที่ใช้หลายฟอร์จ

ถ้าตัวตนของฟอร์จใดยังแยกแยะไม่ได้ รีโปของฟอร์จนั้นจะไม่ป้อนอะไรเข้าสู่กล่องขาเข้าเลย แทนที่จะจับคู่กับทุกอย่าง กล่องขาเข้าจะบอกตามนั้น แทนที่จะอ้างว่าคุณตามทันทุกอย่างแล้ว

กล่องขาเข้าเดียว ทุกฟอร์จ

กล่องขาเข้าและคิว PR กระจายคำขอไปยังทุกฟอร์จที่มีอยู่ในเวิร์กสเปซ แล้วรวมผลลัพธ์เป็นสตรีมเดียว — pull request ของ GitHub และ pull request ของ Bitbucket จะอยู่ข้างกัน เรียงตามเวลา ไม่ได้จัดกลุ่มตามผู้ให้บริการ

ความล้มเหลวถูกแยกออกจากกัน ฟอร์จที่ล่ม ติดขีดจำกัดอัตรา หรือยังไม่ได้เชื่อมต่อ จะไม่ป้อนอะไรเลยและปล่อยให้เจ้าอื่นไม่ถูกแตะต้อง มันไม่เคยทำให้กล่องขาเข้าว่างทั้งใบ รีโปของมันเองยังคงแสดงสถานะล่าสุดที่รู้จักจนกว่ามันจะกลับมา

แต่ละฟอร์จทำอะไรได้บ้าง

ทุกฟอร์จรองรับวงจรหลัก: แสดงรายการและเปิด pull request อ่าน diff แสดงความคิดเห็นในบรรทัดและระดับบนสุด รีวิว รวม และปิด เหนือกว่านั้นแต่ละเจ้าต่างกันจริง และ Control Center จะซ่อนสิ่งที่ฟอร์จทำไม่ได้ แทนที่จะแสดงตัวควบคุมที่ล้มเหลวเงียบ ๆ

ความสามารถ	GitHub	GitLab	Bitbucket
รีวิวแบบเป็นชุด (ที่ค้างอยู่)	✓	✓	—
ขอให้แก้ไข	✓	✓	✓
ซิงค์สถานะ “ดูแล้ว” ต่อไฟล์	✓	—	—
ปฏิกิริยาอีโมจิ	✓	✓	—
ผู้รีวิวแบบทีม / กลุ่ม	✓	✓	—
ผู้รีวิวที่แนะนำ	✓	—	✓
ผลลัพธ์ CI บน PR	✓	✓	✓
เจาะดูขั้นตอน/บันทึกของงาน CI	✓	✓	—
Pull request ที่ซ้อนกัน	✓	—	—
เทมเพลตคำอธิบาย PR	✓	✓	—
การโพลล์การแจ้งเตือน	✓	—	—
โปรไฟล์ผู้ใช้แบบละเอียด	✓	✓	—
PR head ref ฝั่งเซิร์ฟเวอร์	✓	✓	—

เมื่อความสามารถใดขาดไป ฟีเจอร์จะลดทอนลงอย่างตรงไปตรงมา:

สถานะดูแล้ว ยังทำงานได้ แต่เฉพาะบนอุปกรณ์ที่คุณตั้งมันไว้เท่านั้น
รีวิวแบบเป็นชุด บน Bitbucket จะโพสต์ทีละความคิดเห็น ผู้รีวิวจึงเห็นพวกมันมาทีละรายการ ไม่ได้มาพร้อมกันทั้งหมด
ไม่มี PR head ref บน Bitbucket หมายความว่าการเช็กเอาต์ pull request จะดึงสาขาต้นทางตามชื่อ ซึ่งจะล้มเหลวเมื่อสาขานั้นถูกลบไปแล้ว

คำศัพท์

GitLab เรียก pull request ว่า merge request Control Center ใช้คำว่า “pull request” ตลอดโมเดลของตัวเอง และใช้คำเรียกของแต่ละฟอร์จเองเมื่อพูดถึงฟอร์จนั้น

การแก้ปัญหา

รายการ PR ว่างเปล่าและบอกว่าฟอร์จยังไม่ได้เชื่อมต่อ

คุณไม่มีข้อมูลรับรองสำหรับฟอร์จนั้น ลงชื่อเข้าใช้หรือวางโทเค็นใน การตั้งค่า → เวิร์กสเปซ → โปรไฟล์และตัวตน → โฮสต์โค้ด รีโปของฟอร์จอื่นไม่ได้รับผลกระทบ

ฉันเชื่อมต่อฟอร์จแล้ว แต่รีโปของมันยังไม่แสดงอะไร

ตรวจดูคำบรรยายใต้ชื่อของแถวนั้น ถ้ามันขึ้นว่า “ผ่านแอปของเซิร์ฟเวอร์นี้” หรือ “จากสภาพแวดล้อม” แสดงว่ามีข้อมูลรับรองอื่นเป็นคนตอบ ไม่ใช่ตัวที่คุณคาดไว้ — ข้อมูลรับรองของคุณชนะสำหรับทุกสิ่งที่คุณขอ ดังนั้นถ้ามันบอกเป็นอย่างอื่น ของคุณยังไม่ถูกบันทึก

รีโปลงทะเบียนไม่ได้

การลงทะเบียนต้องเข้าเงื่อนไขทั้งสามข้อ: พาธอยู่ภายใน git work tree, มี remote origin และ remote นั้นชี้ไปที่ github.com, gitlab.com หรือ bitbucket.org ดู เพิ่มรีโปในเวิร์กสเปซ

ทุกอย่างหยุดทำงานชั่วขณะหลังใช้งานหนัก

นั่นคือเซอร์กิตเบรกเกอร์ของขีดจำกัดอัตรา ฟอร์จที่ส่งสัญญาณว่าแตะขีดจำกัดหลักจะทำให้ไคลเอนต์ให้คำขอต่อไปล้มเหลวในเครื่องโดยไม่เรียกผ่านเครือข่ายจนกว่าหน้าต่างเวลาจะผ่านไป — พายุการลองใหม่จึงไม่สามารถทำให้ขีดจำกัดลึกลงได้ ความล้มเหลวชั่วคราวจะถูกลองใหม่ด้วย exponential backoff