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

รายงานปัญหา ดูแหล่งที่มา รุ่น Nightly · 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: 1 ป้าย เช่น platform:apple สำหรับปัญหาเฉพาะของ Mac
  7. หากปัญหามีลำดับความสำคัญต่ำและสมาชิกชุมชนคนใหม่สามารถแก้ไขได้ สมาชิก DevEx จะกำหนดป้ายกำกับ good first issue ในขั้นตอนนี้ ปัญหาจะเข้าสู่กลุ่มปัญหาที่ยังไม่จัดการ

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

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

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

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

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

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

ปัญหา

  1. กรองรายการปัญหาตามป้ายกำกับของทีมและป้ายกำกับ untriaged
  2. ตรวจสอบปัญหา
  3. ระบุลําดับความสําคัญและมอบหมายป้ายกํากับ
    1. ทีมย่อยของ DevEx อาจให้ความสำคัญกับปัญหานี้ไปแล้วหากเป็น หน้า 0 จัดลําดับความสําคัญใหม่หากจําเป็น
    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 - ข้อบกพร่องที่มีลำดับความสำคัญต่ำ หรือคำขอฟีเจอร์ที่ไม่น่าจะปิดได้ นอกจากนี้ยังสามารถเปิดอยู่เพื่อจัดลําดับความสําคัญใหม่ได้หากมีผู้ใช้จำนวนมากขึ้นที่ได้รับผลกระทบ
  • กล่องน้ำแข็ง
    • ปัญหาที่เราไม่มีเวลาจัดการหรือ ระยะเวลายอมรับการสนับสนุน เราจะปิดปัญหาเหล่านี้เพื่อระบุว่า ไม่มีใครทำงานนั้นอยู่ แต่จะตรวจสอบความถูกต้องของบัญชี กลับมาใช้ใหม่เมื่อมีผู้คนได้รับผลกระทบมากพอ และถ้าเราต้อง ในการจัดการกับทรัพยากรเหล่านั้น และเช่นเคย โปรดแสดงความคิดเห็นหรือรีแอ็กชันต่อปัญหาเหล่านี้ได้แม้ว่าจะปิดไปแล้วก็ตาม

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

  • 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: การสร้างไฟล์และการประมวลผลมาโคร: 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) ปัญหาเกี่ยวกับ API ของ BUILD และ .bzl (ซึ่งแสดงถึงการผสานรวมของ Bazel กับ Starlark) เกิดขึ้นใน team-Build-Language

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

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