คู่มือสำหรับผู้บำรุงรักษา Bazel

วันที่ รายงานปัญหา ดูแหล่งที่มา ตอนกลางคืน · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

นี่คือคู่มือสำหรับผู้ดูแลโครงการโอเพนซอร์ส Bazel

หากคุณกำลังมองหาวิธีร่วมให้ข้อมูลกับ Bazel โปรดอ่านการมีส่วนร่วมใน Bazel แทน

วัตถุประสงค์ของหน้านี้คือ

  1. ทำหน้าที่เป็นผู้ดูแล แหล่งข้อมูลที่เชื่อถือได้สำหรับการมีส่วนร่วมของโปรเจ็กต์ ขั้นตอนได้
  2. กำหนดความคาดหวังระหว่างผู้สนับสนุนของชุมชนกับโครงการ ผู้ดูแลเท่านั้น

กลุ่มผู้สนับสนุนหลักของ Bazel ได้ทุ่มเท เพื่อจัดการด้านต่างๆ ของโครงการโอเพนซอร์ส ได้แก่

  • กระบวนการเผยแพร่: จัดการกระบวนการเผยแพร่ของ Bazel
  • ทีมสีเขียว: พัฒนาระบบนิเวศของกฎและเครื่องมือที่มีประสิทธิภาพ
  • นักจัดสวนด้านประสบการณ์สำหรับนักพัฒนาซอฟต์แวร์: ส่งเสริมการมีส่วนร่วมจากภายนอก เขียนรีวิว ปัญหาและดึงคำขอ รวมถึงทำให้เวิร์กโฟลว์การพัฒนาเปิดกว้างมากขึ้น

การเปิดตัว

การรวมอย่างต่อเนื่อง

อ่านคู่มือของทีม Green เกี่ยวกับโครงสร้างพื้นฐาน CI ของ Bazel ใน bazelbuild/continuous-integration ที่เก็บได้

วงจรของปัญหา

  1. ผู้ใช้สร้างปัญหาโดยเลือก เทมเพลตปัญหา และแสดงกลุ่ม ที่ยังไม่ได้ตรวจสอบ แบบเปิด ปัญหา
  2. สมาชิกในทีมย่อยด้านประสบการณ์สำหรับนักพัฒนาซอฟต์แวร์ (DevEx) จะตรวจสอบ ปัญหา
    1. หากปัญหาไม่ใช่ข้อบกพร่องหรือคำขอฟีเจอร์ สมาชิก DevEx จะปิดปัญหาและเปลี่ยนเส้นทางผู้ใช้ไปที่ StackOverflow และ bazel-discuss สำหรับ ระดับการเข้าถึงคำถามที่สูงขึ้น
    2. หากปัญหาอยู่ในที่เก็บกฎรายการใดรายการหนึ่งของ เช่น rules_apple สมาชิก DevEx จะโอนปัญหานี้ ไปยังที่เก็บที่ถูกต้อง
    3. หากปัญหาไม่ชัดเจนหรือไม่มีข้อมูล สมาชิก DevEx จะ มอบหมายปัญหากลับไปยังผู้ใช้เพื่อขอข้อมูลเพิ่มเติมก่อนวันที่ ต่อไป กรณีนี้มักเกิดขึ้นเมื่อผู้ใช้ไม่ได้เลือก เทมเพลตปัญหา {: .external} หรือให้ข้อมูลไม่ครบถ้วน
  3. หลังจากตรวจสอบปัญหา สมาชิก DevEx จะตัดสินใจว่าปัญหาต้องการหรือไม่ ความสนใจได้ทันที หากใช่ พวกเขาจะกำหนด P0 ป้ายกำกับลำดับความสำคัญและเจ้าของจากรายการโอกาสในการขายของทีม
  4. สมาชิก DevEx จะกำหนดป้ายกำกับ untriaged และทีม 1 ทีมเท่านั้น ป้ายกำกับ [label] สำหรับการกำหนดเส้นทาง
  5. สมาชิก DevEx ยังกำหนดป้ายกำกับ type: เพียง 1 รายการเท่านั้น เช่น type: bug หรือ type: feature request ทั้งนี้ขึ้นอยู่กับประเภทของปัญหา
  6. สำหรับปัญหาเฉพาะแพลตฟอร์ม สมาชิก DevEx จะได้รับป้ายกำกับ platform: 1 ป้าย เช่น platform:apple สำหรับปัญหาเฉพาะของ Mac
  7. หากปัญหามีความสำคัญต่ำและแก้ไขได้โดยชุมชนใหม่ ผู้มีส่วนร่วมและสมาชิก DevEx จะกำหนดป้ายกำกับ good first issue ในขั้นนี้ ปัญหาจะอยู่ในกลุ่มเปิดที่ยังไม่ได้นำเข้า ปัญหา

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

เมื่อปัญหาได้รับการแก้ไขแล้วก็จะปิดได้

วงจรของคำขอพุล

  1. ผู้ใช้สร้างคำขอพุล
  2. หากคุณเป็นสมาชิกของทีม Bazel และส่งการประชาสัมพันธ์ไปยังพื้นที่ของคุณ คุณต้องรับผิดชอบในการกำหนดป้ายกำกับของทีมและค้นหาสิ่งที่ดีที่สุด ผู้ตรวจสอบเนื้อหา
  3. มิฉะนั้น ระหว่างการคัดแยกรายวัน สมาชิก DevEx จะมอบหมาย ป้ายกำกับทีม และหัวหน้าด้านเทคนิค (TL) ของทีมสำหรับการกำหนดเส้นทาง
    1. TL อาจมอบหมายให้บุคคลอื่นตรวจสอบการประชาสัมพันธ์ได้
  4. ผู้รีวิวที่ได้รับมอบหมายจะตรวจสอบการประชาสัมพันธ์และทำงานร่วมกับผู้เขียนจนกว่าจะ ได้รับการอนุมัติหรือถูกปฏิเสธ
  5. หากได้รับอนุมัติ ผู้ตรวจสอบจะนำเข้าสัญญาผูกมัดของการประชาสัมพันธ์ไปยัง ระบบควบคุมเวอร์ชันภายในสำหรับการทดสอบเพิ่มเติม เนื่องจาก Bazel เป็นบิลด์เดียวกัน ที่ใช้เป็นการภายในที่ Google เราต้องทดสอบการดำเนินการ PR ทั้งหมดกับ ชุดทดสอบภายใน นี่คือเหตุผลที่เราไม่ผสาน PR โดยตรง
  6. หากคอมมิตที่นำเข้าผ่านการทดสอบภายในทั้งหมด คอมมิตจะถูกบีบ และส่งออกกลับไปยัง GitHub
  7. เมื่อคอมมิตดังกล่าวรวมอยู่ในรายการหลัก GitHub จะปิด PR โดยอัตโนมัติ

ทีมของฉันเป็นเจ้าของป้ายกำกับ ฉันควรทำอย่างไร

ทีมย่อยต้องคัดแยกปัญหาทั้งหมดในป้ายกำกับที่ตนเองเป็นเจ้าของ แนะนำให้ทำทุกสัปดาห์

ปัญหา

  1. กรองรายการปัญหาตามป้ายกำกับของทีมและป้ายกำกับ untriaged
  2. ตรวจสอบปัญหา
  3. ระบุลำดับความสำคัญและกำหนดป้ายกำกับ
    1. ปัญหาอาจได้รับการจัดลำดับความสำคัญโดยทีมย่อย DevEx อยู่แล้วหากเป็น หน้า 0 จัดลำดับความสำคัญใหม่หากจำเป็น
    2. แต่ละปัญหาต้องมีป้ายกํากับลำดับความสำคัญเพียง 1 ป้ายเท่านั้น หากมี ปัญหาคือระดับ P0 หรือ P1 ที่เราถือว่ากำลังดำเนินการอยู่
  4. นำป้ายกำกับ untriaged ออก

โปรดทราบว่าคุณต้องอยู่ใน bazelbuild องค์กร จึงจะเพิ่มหรือนำป้ายกำกับออกได้

ดึงคำขอ

  1. กรองรายการคำขอพุลตามป้ายกำกับทีม
  2. ตรวจสอบคำขอพุลที่เปิดอยู่
    1. ไม่บังคับ: หากคุณได้รับมอบหมายให้ตรวจสอบแต่ไม่เหมาะสม ให้มอบหมายผู้ตรวจสอบที่เหมาะสมอีกครั้งเพื่อดำเนินการตรวจสอบโค้ด
  3. ทำงานร่วมกับผู้สร้างการดึงคำขอเพื่อตรวจสอบโค้ดให้เสร็จสมบูรณ์
  4. อนุมัติการประชาสัมพันธ์
  5. ตรวจสอบว่าการทดสอบทั้งหมดผ่าน
  6. นำเข้าแพตช์ไปยังระบบควบคุมเวอร์ชันภายในและเรียกใช้ ที่ส่งล่วงหน้า
  7. ส่งแพตช์ภายใน หากแพตช์ส่งและส่งออกสำเร็จ GitHub จะปิดการประชาสัมพันธ์โดยอัตโนมัติ

ลำดับความสำคัญ

ผู้ดูแลจะใช้คำนิยามสำหรับลำดับความสำคัญต่อไปนี้ในการคัดแยก ปัญหา

  • P0 - ใช้งานไม่ได้มาก ฟังก์ชันที่ทำให้รุ่น Bazel (ไม่รวมรุ่นที่เผยแพร่) ไม่สามารถใช้งานได้ หรือบริการล่มที่ส่งผลต่อการพัฒนา Bazel อย่างรุนแรง ซึ่งรวมถึงการถดถอยที่พบในรุ่นใหม่ซึ่งบล็อก ผู้ใช้จำนวนมาก หรือการเปลี่ยนแปลงที่เข้ากันไม่ได้ ซึ่งไม่ได้เป็น เป็นไปตามข้อกำหนด เปลี่ยน แต่ไม่มีทางปฏิบัติที่ใช้ได้จริง
  • P1 - ข้อบกพร่องร้ายแรง หรือ ที่ควรระบุในรุ่นถัดไป หรือปัญหาร้ายแรงที่ ส่งผลต่อผู้ใช้จำนวนมาก (รวมถึงการพัฒนาโครงการ Bazel) มีวิธีแก้ปัญหาเชิงปฏิบัติ โดยปกติแล้วไม่จําเป็นต้องดําเนินการใดๆ ในทันที ใน เป็นที่ต้องการอย่างมาก และได้วางแผนไว้ในแผนกลยุทธ์ของไตรมาสปัจจุบันแล้ว
  • P2 - ข้อบกพร่องหรือฟีเจอร์ ที่ควรแก้ไข แต่เรายังไม่ได้ดำเนินการใดในขณะนี้ จัดการปัญหาแบบเรียลไทม์ ใน Bazel ที่เปิดตัว ซึ่งไม่สะดวกสำหรับผู้ใช้ที่ต้องการ มีการจัดการในรุ่นต่อๆ ไปและ/หรือมีวิธีการแก้ปัญหาที่ง่ายดาย
  • P3 - ข้อบกพร่องเล็กๆ น้อยๆ ที่ไม่พึงประสงค์ แก้ไขหรือปรับปรุง ซึ่งมีผลกระทบเพียงเล็กน้อย ไม่ได้ให้ความสำคัญกับแผนงานของ Bazel หรือ ผลงานที่ใกล้จะเปิดตัว แต่เราขอแนะนำให้การสนับสนุนของชุมชน
  • P4 - ข้อบกพร่องที่มีลำดับความสำคัญต่ำ หรือคำขอฟีเจอร์ที่ไม่น่าจะปิดได้ นอกจากนี้ยังสามารถเปิดค้างไว้ จัดลำดับความสำคัญซ้ำได้หากมีผู้ใช้ได้รับผลกระทบมากขึ้น
  • กล่องน้ำแข็ง
    • ปัญหาที่เราไม่มีเวลาจัดการหรือ ระยะเวลายอมรับการสนับสนุน เราจะปิดปัญหาเหล่านี้เพื่อระบุว่า ไม่มีใครทำงานนั้นอยู่ แต่จะตรวจสอบความถูกต้องของบัญชี กลับมาใช้ใหม่เมื่อมีผู้คนได้รับผลกระทบมากพอ และถ้าเราต้อง ในการจัดการกับทรัพยากรเหล่านั้น คุณแสดงความคิดเห็นหรือเพิ่มรีแอ็กชันได้เหมือนเช่นเคย ปัญหาเหล่านี้ได้แม้ว่าจะปิดไปแล้วก็ตาม

ป้ายกำกับทีม

  • team-Android: ปัญหาสำหรับทีม Android
  • team-Bazel: ปัญหาทั่วไปเกี่ยวกับผลิตภัณฑ์/กลยุทธ์ของ Bazel
  • team-CLI: UI ของคอนโซล
  • team-Configurability: ปัญหาสำหรับทีมการกำหนดค่า ประกอบด้วย: การกำหนดค่าบิลด์หลักและระบบการเปลี่ยน ไม่รวมถึงการเปลี่ยนแปลงแฟล็กใหม่หรือที่มีอยู่
  • team-Core: Skyframe, การค้นหาด้วย Bazel, BEP, การแยกวิเคราะห์ตัวเลือก, bazelrc
  • team-Documentation: ปัญหาสำหรับทีมเอกสารประกอบ
  • team-ExternalDeps: การจัดการทรัพยากร Dependency ภายนอก, Bzlmod, ที่เก็บระยะไกล, ไฟล์ WORKSPACE
  • team-Loading-API: การประมวลผลไฟล์และมาโคร: ป้ายกำกับ, แพ็กเกจ(), ระดับการมองเห็น, glob
  • team-Local-Exec: ปัญหาสำหรับทีมดำเนินการ (ในพื้นที่)
  • team-OSS: ปัญหาสำหรับทีม Bazel OSS: การติดตั้ง กระบวนการเผยแพร่ บรรจุภัณฑ์ Bazel เว็บไซต์ โครงสร้างพื้นฐานของเอกสาร
  • team-Performance: ปัญหาสำหรับทีม Bazel Performance
  • team-Remote-Exec: ปัญหาสำหรับทีมดำเนินการ (ระยะไกล)
  • team-Rules-API: API สำหรับการเขียนกฎ/มุมมอง ได้แก่ ผู้ให้บริการ, ไฟล์, การดำเนินการ, อาร์ติแฟกต์
  • team-Rules-CPP / team-Rules-ObjC: ปัญหาเกี่ยวกับกฎ C++/Objective-C รวมถึงตรรกะกฎของ Apple แบบเนทีฟ
  • team-Rules-Java: ปัญหาของกฎ Java
  • team-Rules-Python: ปัญหาเกี่ยวกับกฎ Python แบบเนทีฟ
    • รายชื่อติดต่อ: rickeylev
  • team-Rules-Server: ปัญหาของกฎฝั่งเซิร์ฟเวอร์ที่รวมอยู่ใน Bazel
  • team-Starlark-Integration: การผสานรวม Bazel + Starlark ที่ไม่ใช่ API รวมถึงวิธีที่ Bazel ทริกเกอร์ล่าม Starlark, Stardoc, การแทรกในตัว การเข้ารหัสอักขระ ไม่รวมถึงปัญหาเกี่ยวกับภาษา BUILD หรือ .bzl
  • team-Starlark-Interpreter: ปัญหาสำหรับอินเทอร์พรีเตอร์ของ Starlark (ทุกอย่างใน java.net.starlark) ปัญหาเกี่ยวกับ API ของ BUILD และ .bzl (ซึ่งแสดงถึงการผสานรวมของ Bazel กับ Starlark) เกิดขึ้นใน team-Build-Language

สำหรับปัญหาใหม่ เราได้เลิกใช้งานป้ายกำกับ category: * เพื่อให้ทีมช่วยเหลือ ป้ายกำกับ

ดูรายการป้ายกำกับทั้งหมดได้ที่นี่