สมุนไพร

รายงานปัญหา ดูแหล่งที่มา

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

ภาพรวม

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

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

องค์ประกอบสำคัญ 2 ประการของความไม่สละสลวยคือ:

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

ประโยชน์

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

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

การระบุความไม่เป็นธรรมชาติ

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

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

การแก้ปัญหาบิลด์ที่ไม่เฉพาะตัว

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

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

ความสุจริตกับบาเซล

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