สมุนไพร

รายงานปัญหา ดูซอร์สโค้ด รุ่น Nightly · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

ภาพรวม

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

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

ลักษณะสำคัญ 2 ประการของการป้องกันการรั่วซึม ได้แก่

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

ประโยชน์

ประโยชน์หลักๆ ของบิลด์แบบปิดผนึก ได้แก่

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

การระบุการปิดไม่สนิท

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

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

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

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

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

ความเป็นโมฆะด้วย Bazel

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