สมุนไพร

Nightly · 9.0 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

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

ภาพรวม

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

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

ด้านสำคัญ 2 ประการของความแนบสนิทมีดังนี้

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

ข้อดี

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

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

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

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

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

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

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

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

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

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