สมุนไพร

Nightly · 9.2 · 9.1 · 9.0 · 8.7 · 8.6

หน้านี้ครอบคลุมถึงความสมบูรณ์ ประโยชน์ของการใช้บิลด์ที่สมบูรณ์ และ กลยุทธ์ในการระบุลักษณะการทำงานที่ไม่สมบูรณ์ในบิลด์

ภาพรวม

เมื่อได้รับซอร์สโค้ดอินพุตและการกำหนดค่าผลิตภัณฑ์เดียวกัน ระบบบิลด์แบบปิดจะแสดงผลลัพธ์เดียวกันเสมอโดยแยกบิลด์จากการเปลี่ยนแปลงในระบบโฮสต์

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

ด้านสำคัญ 2 ประการของความไม่สามารถเข้าถึงได้มีดังนี้

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

ข้อดี

ประโยชน์หลักๆ ของบิลด์แบบเฮอร์เมติกมีดังนี้

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

การระบุการไม่เป็นแบบเฮอร์มีติก

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

  • การประมวลผลโดยพลการในไฟล์ .mk
  • การดำเนินการหรือเครื่องมือที่สร้างไฟล์แบบไม่แน่นอน ซึ่งมักเกี่ยวข้องกับ Build ID หรือการประทับเวลา
  • ไบนารีของระบบที่แตกต่างกันในโฮสต์ (เช่น ไบนารี /usr/bin เส้นทางแบบสัมบูรณ์ คอมไพเลอร์ C++ ของระบบสำหรับการกำหนดค่าอัตโนมัติของกฎ C++ ดั้งเดิม)
  • การเขียนไปยังทรีต้นทางระหว่างการบิลด์ ซึ่งจะป้องกันไม่ให้ใช้แหล่งที่มา เดียวกันกับเป้าหมายอื่น บิลด์แรกจะเขียนไปยังแหล่งที่มา ของทรี ซึ่งจะแก้ไขทรีแหล่งที่มาสำหรับเป้าหมาย A จากนั้นการพยายามสร้างเป้าหมาย B อาจ ล้มเหลว

การแก้ปัญหาการสร้างที่ไม่ใช่แบบปิด

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

  • ตรวจสอบว่าไม่มีการสร้างตามลำดับที่ว่างเปล่า: หากคุณเรียกใช้ make และสร้างสำเร็จ การเรียกใช้การสร้างอีกครั้งไม่ควรสร้างเป้าหมายใหม่ หากคุณเรียกใช้แต่ละขั้นตอนการสร้าง 2 ครั้งหรือในระบบที่แตกต่างกัน ให้เปรียบเทียบแฮชของเนื้อหาไฟล์และรับผลลัพธ์ที่แตกต่างกัน บิลด์จะทำซ้ำไม่ได้
  • ทำตามขั้นตอนเพื่อแก้ไขข้อบกพร่องของแคชที่เข้าชมในเครื่อง จากเครื่องไคลเอ็นต์ที่มีศักยภาพหลากหลายเพื่อให้แน่ใจว่าคุณจะพบกรณีที่สภาพแวดล้อมของไคลเอ็นต์รั่วไหลไปยังการดำเนินการ
  • เรียกใช้บิลด์ภายในคอนเทนเนอร์ Docker ที่มีเพียง โครงสร้างแหล่งที่มาที่เช็คเอาต์และรายการเครื่องมือโฮสต์ที่ชัดเจน การหยุดชะงักของบิลด์และ ข้อความแสดงข้อผิดพลาดจะตรวจจับทรัพยากร Dependency ของระบบโดยนัย
  • ค้นหาและแก้ไขปัญหาเกี่ยวกับความสมบูรณ์โดยใช้กฎการดำเนินการจากระยะไกล
  • เปิดใช้แซนด์บ็อกซ์แบบเข้มงวด ที่ระดับการดำเนินการแต่ละรายการ เนื่องจากสถานะของการดำเนินการในบิลด์อาจมีผลต่อ บิลด์หรือเอาต์พุต
  • กฎของ Workspace อนุญาตให้นักพัฒนาแอปเพิ่มการอ้างอิงไปยัง Workspace ภายนอกได้ แต่ก็ มีความยืดหยุ่นมากพอที่จะอนุญาตให้มีการประมวลผลที่กำหนดเองในกระบวนการนี้ คุณดูบันทึกการดำเนินการบางอย่างที่อาจไม่ใช่แบบเฮอร์มิติกในกฎพื้นที่ทำงานของ Bazel ได้โดย เพิ่มแฟล็ก --experimental_workspace_rules_log_file=PATH ใน คำสั่ง Bazel

การเป็นระบบปิดด้วย Bazel

ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีที่โปรเจ็กต์อื่นๆ ประสบความสำเร็จในการใช้บิลด์แบบเฮอร์เมติกกับ Bazel ได้ในการพูดคุยที่ BazelCon ดังนี้