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

รายงานปัญหา ดูซอร์สโค้ด รุ่น Nightly · 8.0 7.4 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 รายการสําหรับการกำหนดเส้นทาง
  5. สมาชิก DevEx จะกำหนดป้ายกำกับ type: เพียง 1 รายการ เช่น type: bug หรือ type: feature request ตามประเภทของปัญหา
  6. สำหรับปัญหาเฉพาะแพลตฟอร์ม สมาชิก DevEx จะกำหนดป้ายกำกับ platform: รายการเดียว เช่น platform:apple สำหรับปัญหาเฉพาะ Mac
  7. หากปัญหามีลำดับความสำคัญต่ำและสมาชิกชุมชนคนใหม่สามารถแก้ไขได้ สมาชิก DevEx จะกำหนดป้ายกำกับ good first issue ในขั้นตอนนี้ ปัญหาจะเข้าสู่กลุ่มปัญหาที่ยังไม่จัดการ

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

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

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

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

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

ทีมย่อยต้องจัดลําดับความสําคัญของปัญหาทั้งหมดในป้ายกำกับที่ตนเป็นเจ้าของ โดยควรทำเป็นรายสัปดาห์

ปัญหา

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

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

คำขอพุล

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

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

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

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

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

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

สําหรับปัญหาใหม่ เราเลิกใช้งานป้ายกํากับ category: * แล้วหันมาใช้ป้ายกํากับของทีมแทน

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