สมุนไพร

รายงานปัญหา ดูแหล่งที่มา Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

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

ภาพรวม

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

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

ด้านสำคัญ 2 ประการของความแน่นหนา ได้แก่

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

ข้อดี

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

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

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

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

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

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

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

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

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

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