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

นี่คือคำแนะนำสำหรับผู้ดูแลโปรเจ็กต์โอเพนซอร์ส Bazel

หากต้องการมีส่วนร่วมใน Bazel โปรดอ่าน การมีส่วนร่วมใน Bazel แทน

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

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

กลุ่มผู้มีส่วนร่วมหลักของ Bazel มี ทีมย่อยที่ทำหน้าที่จัดการส่วนต่างๆ ของโปรเจ็กต์โอเพนซอร์ส ได้แก่

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

การเผยแพร่

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

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

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

  1. ผู้ใช้สร้างปัญหาโดยเลือกเทมเพลตปัญหาใดเทมเพลตหนึ่ง แล้วระบบจะนำปัญหาดังกล่าวไปรวมไว้ในกลุ่มปัญหาที่เปิดอยู่ซึ่งยังไม่ได้รับการตรวจสอบ
  2. สมาชิกในทีมย่อย Developer Experience (DevEx) ที่หมุนเวียนกันจะตรวจสอบปัญหา
    1. หากปัญหาไม่ใช่ข้อบกพร่อง หรือคำขอฟีเจอร์ สมาชิก DevEx มักจะปิดปัญหาและเปลี่ยนเส้นทางผู้ใช้ไปยัง StackOverflow และ bazel-discuss เพื่อให้ คำถามได้รับการมองเห็นมากขึ้น
    2. หากปัญหาอยู่ในที่เก็บกฎที่ชุมชนเป็นเจ้าของ เช่น rules_apple สมาชิก DevEx จะโอนปัญหานี้ไปยังที่เก็บที่ถูกต้อง
    3. หากปัญหาไม่ชัดเจนหรือมีข้อมูลขาดหายไป สมาชิก DevEx จะกำหนดปัญหาให้กับผู้ใช้เพื่อขอข้อมูลเพิ่มเติมก่อนดำเนินการต่อ ซึ่งมักเกิดขึ้นเมื่อผู้ใช้ไม่ได้เลือก เทมเพลตปัญหา ที่ถูกต้อง {: .external} หรือให้ข้อมูลไม่ครบถ้วน
  3. หลังจากตรวจสอบปัญหาแล้ว สมาชิก DevEx จะตัดสินใจว่าปัญหาต้องได้รับการดำเนินการในทันทีหรือไม่ หากต้องดำเนินการ สมาชิกจะกำหนดป้ายกำกับลำดับความสำคัญ P0 priority และเจ้าของจากรายชื่อหัวหน้าทีม
  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 ในขั้นตอนนี้ ปัญหาจะถูกนำไปรวมไว้ในกลุ่มปัญหาที่เปิดอยู่ซึ่งยังไม่ได้รับการตรวจสอบuntriaged open issues

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

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

วงจรของ Pull Request

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

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

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

ปัญหา

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

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

Pull Request

  1. กรองรายการ Pull Request ตามป้ายกำกับทีม
  2. ตรวจสอบ Pull Request ที่เปิดอยู่
    1. ไม่บังคับ: หากคุณได้รับมอบหมายให้ตรวจสอบแต่ไม่เหมาะสมที่จะดำเนินการ ให้กำหนดผู้ตรวจสอบที่เหมาะสมเพื่อทำการตรวจสอบโค้ดใหม่
  3. ทำงานร่วมกับผู้สร้าง Pull Request เพื่อทำการตรวจสอบโค้ดให้เสร็จสมบูรณ์
  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: ปัญหาสำหรับทีม Configurability ซึ่งรวมถึงการกำหนดค่าบิลด์หลักและระบบการเปลี่ยนสถานะ ไม่ รวม: การเปลี่ยนแปลงแฟล็กใหม่หรือที่มีอยู่
  • team-Core: Skyframe, การค้นหา bazel, BEP, การแยกวิเคราะห์ตัวเลือก, bazelrc
  • team-Documentation: ปัญหาสำหรับทีมเอกสารประกอบ
  • team-ExternalDeps: การจัดการการขึ้นต่อกันภายนอก, Bzlmod, ที่เก็บระยะไกล, ไฟล์ WORKSPACE
  • team-Loading-API: การประมวลผลไฟล์ BUILD และมาโคร: ป้ายกำกับ, package(), visibility, glob
  • team-Local-Exec: ปัญหาสำหรับทีม Execution (Local)
  • team-OSS: ปัญหาสำหรับทีม Bazel OSS: การติดตั้ง, กระบวนการเผยแพร่, การแพ็กเกจ Bazel, เว็บไซต์, โครงสร้างพื้นฐานของเอกสารประกอบ
  • team-Performance: ปัญหาสำหรับทีม Bazel Performance
  • team-Remote-Exec: ปัญหาสำหรับทีม Execution (Remote)
  • team-Rules-API: API สำหรับการเขียนกฎ/แง่มุมต่างๆ: ผู้ให้บริการ, runfiles, การดำเนินการ, อาร์ติแฟกต์
  • 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: * และใช้ป้ายกำกับทีมแทน

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