สมุนไพร

Nightly · 9.1 · 9.0 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 8.1

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

ภาพรวม

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

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

การเป็นระบบปิดมี 2 ด้านที่สำคัญ ได้แก่

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

สิทธิประโยชน์

ข้อดีหลักๆ ของบิลด์ที่เป็นระบบปิดมีดังนี้

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

ระบุการไม่เป็นระบบปิด

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

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

การแก้ปัญหาบิลด์ที่ไม่เป็นระบบปิด

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

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

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

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