การสนทนาบน PR

pull request เป็นที่ที่บทสนทนาเกี่ยวกับโค้ดเกิดขึ้นอยู่แล้ว การสนทนาบน PR ทำให้มัน กลายเป็นพื้นผิวหนึ่งบนเวิร์กสเปซของ Control Center เช่นเดียวกับที่ สะพานแชททำให้ Slack เป็นพื้นผิวแบบนั้น: @mention บอต GitHub App ของเซิร์ฟเวอร์บน PR ตอบกลับในเธรดรีวิวของมัน หรือเพิ่มป้ายกำกับ ai-review แล้วงานก็จะเกิดขึ้นในสเปซรีวิวของ PR — ภายใต้การระบุที่มาและกฎคุม ชุดเดียวกับทุกอย่างที่พิมพ์ในแอป ความคิดเห็นยังถูกกั้นด้วยสมาชิกภาพ ส่วนป้ายกำกับ ไม่ถูกกั้น เพราะมันไม่มีผู้เขียน คำตอบของบอตกลับไปบน GitHub ในช่องทางที่คำถามถูกถาม

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

การโพลล์คือช่องทางขนส่ง

ช่องทางพุชเดียวของ GitHub สำหรับแอปคือ webhook และ webhook ต้องมี URL ขาเข้า — ซึ่งเป็นสิ่งเดียวที่พื้นผิวนี้จงใจไม่ต้องใช้เลย การค้นหาจึงเป็นการกวาด: ทุก ๆ ประมาณหนึ่งนาที การค้นหาแบบใช้ alias หนึ่งครั้งต่อการติดตั้งแอปแต่ละรายการจะถาม GitHub ขอ PR ที่กล่าวถึงบอต (หรือ slug ย่อของมัน) และขอ PR ที่เปิดอยู่ซึ่งมี ป้ายกำกับรีวิว ส่วน PR ที่มีสเปซรีวิวอยู่แล้วจะถูกอ่านเธรดความคิดเห็น และทุกอย่าง จะถูก diff ด้วย id ของความคิดเห็นเทียบกับสิ่งที่เห็นในการกวาดครั้งก่อน

ผลที่ตามมาของการออกแบบนี้ควรค่าแก่การระบุให้ชัด:

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

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

สมาชิกภาพเป็นตัวให้สิทธิ์ ไม่ใช่ความคิดเห็น

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

การปฏิเสธไว้ก่อนเมื่อไม่แน่ใจมีหน้าตาเป็นบันได และทุกขั้นจะตอบกลับในเธรดที่มัน ปฏิเสธ:

login ที่ไม่รู้จัก — ยังไม่ได้เชื่อม หรือเชื่อมโดยคนที่ไม่ใช่สมาชิกของ เวิร์กสเปซนี้ — จะได้รับคำบอกให้ลงชื่อเข้าใช้และตรวจสอบว่าตนเป็นสมาชิก
สมาชิกแบบอ่านอย่างเดียว (viewer หรือ guest) จะได้รับแจ้งว่าบทบาทของตน เริ่มงานไม่ได้

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

ป้ายกำกับ ai-review ไม่มีผู้เขียนให้เทียบตัวตน จึงไม่ต้องปีนบันไดนี้ การเพิ่มมัน จะเริ่มรีวิวในเวิร์กสเปซที่เชื่อมรีโพสิทอรีอยู่แล้ว

สองตัวตน โดยเจตนา

แต่ละฝ่ายของการสนทนาถือตัวตนที่ต่างกัน และความต่างนั้นคือตัวฟีเจอร์เอง:

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

การเผยแพร่ข้อค้นพบจากรีวิวกลับไปยัง GitHub ยังเป็นการตัดสินใจของคน ซึ่งทำใน Control Center การกล่าวถึงสามารถ เริ่ม รีวิวได้ มีเพียงมนุษย์เท่านั้นที่เผยแพร่มัน

ตัวกันการวนซ้ำ และชื่อย่อ

ทุกอย่างที่เขียนโดยบัญชีบอตจะถูกทิ้งก่อนที่ประตูใด ๆ จะทำงาน — ทั้งของเราโดยเฉพาะ และทุกส่วนต่อท้าย [bot] บอตรีวิวของแอปอื่นจึงปลุกของเราไม่ได้เช่นกัน หากไม่มี สิ่งนี้ คำตอบของบอตเองจะมาถึงในฐานะความคิดเห็นใหม่และทริกเกอร์มันซ้ำไม่รู้จบ

ส่วนต่อท้าย [bot] ยังเป็นเหตุผลที่รูปแบบย่อมีอยู่ GitHub ตรึง login ของบัญชีแอป ไว้ที่ <slug>[bot] ไม่มี autocomplete ให้ และไม่เคยแปลง @slug เป็นแอป — การยอมรับ slug เปล่า ๆ จึงเป็นการตัดสินใจของตัวจับคู่ของเรา และการค้นพบมันต้องใช้ ช่องทางค้นหาข้อความความคิดเห็นแบบดิบ แทนที่จะใช้ดัชนีการกล่าวถึงของ GitHub ต้นทุนนี้ถูกบอกตรง ๆ มากกว่าเลี่ยงให้เนียน: ผู้ใช้ที่เป็นมนุษย์ซึ่งใช้ slug เดียวกับ แอป จะเรียกหาบอตทุกครั้งที่มีการกล่าวถึงตัวเองในรูปแบบย่อ ชื่อแอปที่โดดเด่นทำให้ การชนกันนี้เป็นเพียงสมมติ

สิ่งที่จงใจไม่เสนอให้

ไม่มีการเผยแพร่อัตโนมัติ ข้อค้นพบไปอยู่ในสเปซรีวิว การเผยแพร่ไปยัง GitHub เป็นการกระทำของมนุษย์ที่แยกต่างหาก
ไม่มีการเดาตัวตน ผู้เขียนต้องเทียบได้กับสมาชิกหนึ่งคนเท่านั้น หรือไม่ก็ถูก ปฏิเสธ — ไม่มีการระบุที่มาแบบคาดเดา
ไม่มี webhook ของ GitHub App พื้นผิวนี้ไม่เคยลงทะเบียนมัน จึงไม่มี URL ขาเข้า ที่ต้องเปิดเผยสำหรับความคิดเห็นบน PR webhook อื่น ๆ ของผลิตภัณฑ์ (ไปป์ไลน์ การซิงค์ตั๋วงาน) เป็นการตั้งค่าแยกต่างหากและเป็นทางเลือก

ดูเพิ่มเติม

คุยกับ Control Center จาก GitHub PR: คู่มือวิธีทำสำหรับทั้งหมดนี้
สะพานแชท: การตัดสินใจสามข้อเดียวกัน ที่ทำไว้ สำหรับแชท
สร้าง GitHub App: ตัวตนของบอตมาจากไหน
การทำงานร่วมกันแบบหลายคน — ตัวตน สมาชิกภาพ และการแสดงสถานะออนไลน์: ตัวตนหลักและบทบาทที่ login ต้องเทียบผ่าน
กฎคุม: เอเจนต์ที่ตอบได้รับอนุญาตให้ทำอะไรได้บ้าง
ใช้รีวิวด้วย AI: ไปป์ไลน์ที่การกล่าวถึง หรือป้ายกำกับเริ่มขึ้น