คำถามที่พบบ่อย

หน้านี้จะตอบคำถามที่พบบ่อยบางข้อเกี่ยวกับการพึ่งพาภายนอกใน Bazel

MODULE.bazel

ฉันควรกำหนดเวอร์ชันของโมดูล Bazel อย่างไร

การตั้งค่า version ด้วยคำสั่ง module ในไฟล์เก็บถาวรต้นฉบับ MODULE.bazel อาจมีข้อเสียและผลข้างเคียงที่ไม่พึงประสงค์หลายประการหากไม่ได้รับการ จัดการอย่างระมัดระวัง

• การทำซ้ำ: การเผยแพร่โมดูลเวอร์ชันใหม่มักจะเกี่ยวข้องกับการเพิ่มเวอร์ชันใน MODULE.bazel และการติดแท็กการเผยแพร่ ซึ่งเป็น 2 ขั้นตอนแยกกันที่อาจไม่ซิงค์กัน แม้ว่าการทำงานอัตโนมัติจะช่วยลดความเสี่ยงนี้ได้ แต่การหลีกเลี่ยงไปเลยนั้นง่ายและปลอดภัยกว่า

• ความไม่สอดคล้องกัน: ผู้ใช้ที่ลบล้างโมดูลด้วยคอมมิตที่เฉพาะเจาะจงโดยใช้ การลบล้างที่ไม่ใช่รีจิสทรีจะเห็นเวอร์ชันที่ไม่ถูกต้อง เช่น หาก MODULE.bazelในไฟล์เก็บถาวรต้นฉบับตั้งค่าversion = "0.3.0"แต่ มีการคอมมิตเพิ่มเติมตั้งแต่การเผยแพร่นั้น ผู้ใช้ที่ลบล้าง ด้วยคอมมิตใดคอมมิตหนึ่งเหล่านั้นจะยังคงเห็น0.3.0 ในความเป็นจริง เวอร์ชันควรแสดงให้เห็นว่าเวอร์ชันนั้นใหม่กว่าเวอร์ชันที่เผยแพร่แล้ว เช่น 0.3.1-rc1

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

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

โดยปกติแล้วกระบวนการนี้จะเป็นแบบอัตโนมัติ เช่น ที่เก็บข้อมูลกฎตัวอย่าง rules-templateexample rule repository ใช้ bazel-contrib/publish-to-bcr publish.yaml GitHub Action เพื่อ เผยแพร่การเผยแพร่ไปยัง BCR การดำเนินการจะสร้างแพตช์สำหรับไฟล์เก็บถาวรต้นฉบับที่มีเวอร์ชันที่เผยแพร่MODULE.bazel แพตช์นี้จะจัดเก็บไว้ในรีจิสทรีและจะนำไปใช้เมื่อมีการดึงข้อมูลโมดูลระหว่างการแก้ปัญหาการพึ่งพาภายนอกของ Bazel

วิธีนี้จะช่วยให้เวอร์ชันในการเผยแพร่ในรีจิสทรีได้รับการตั้งค่าเป็น เวอร์ชันที่เผยแพร่แล้วอย่างถูกต้อง ดังนั้น bazel_dep, single_version_override และ multiple_version_override จะทำงานตามที่คาดไว้ ในขณะเดียวกันก็หลีกเลี่ยงปัญหาที่อาจเกิดขึ้นเมื่อทำการลบล้างที่ไม่ใช่รีจิสทรี เนื่องจากเวอร์ชันในไฟล์เก็บถาวรต้นฉบับจะเป็นค่าเริ่มต้น ('') ซึ่งระบบจะจัดการ อย่างถูกต้องเสมอ (เนื่องจากเป็นค่าเวอร์ชันเริ่มต้น) และจะทำงานตามที่ คาดไว้เมื่อเรียงลำดับ (ระบบจะถือว่าสตริงว่างเป็นเวอร์ชันสูงสุด)

ระดับความเข้ากันได้คืออะไร

คุณควรหยุดใช้ compatibility_level

การเพิ่ม compatibility_level จะทำให้เกิดความขัดแย้งของเวอร์ชันที่ผู้ใช้ปลายทางแก้ไขได้ยาก ดังนั้น ตั้งแต่ Bazel 8.6.0 และ 9.1.0 เป็นต้นไป ทั้ง compatibility_level และ max_compatibility_level จะไม่มีการดำเนินการ

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

เอกสารประกอบเดิม:

compatibility_level ของโมดูล Bazel ควรเพิ่มขึ้น ในคอมมิตเดียวกัน กับที่ทำการเปลี่ยนแปลงที่เข้ากันไม่ได้กับเวอร์ชันก่อนหน้า ("การเปลี่ยนแปลงที่ทำให้เกิดการหยุดทำงาน")

อย่างไรก็ตาม Bazel อาจแสดงข้อผิดพลาดหากตรวจพบว่ามีเวอร์ชันของ โมดูลเดียวกัน ที่มี ระดับความเข้ากันได้ต่างกัน อยู่ในกราฟทรัพยากร Dependency ที่แก้ปัญหาแล้ว กรณีนี้อาจเกิดขึ้นได้ เช่น เมื่อโมดูล 2 โมดูลขึ้นอยู่กับเวอร์ชันของโมดูลที่ 3 ที่มีระดับความเข้ากันได้ต่างกัน

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

เหตุใด MODULE.bazel จึงไม่รองรับ load

ระหว่างการแก้ปัญหาทรัพยากร Dependency ระบบจะดึงข้อมูลไฟล์ MODULE.bazel ของทรัพยากร Dependency ภายนอกทั้งหมดที่อ้างอิงจากรีจิสทรี ในขั้นตอนนี้ ระบบจะยังไม่ดึงข้อมูลไฟล์เก็บถาวรต้นฉบับของการพึ่งพา ดังนั้นหากไฟล์ MODULE.bazel load ไฟล์อื่น Bazel จะไม่มีวิธีดึงข้อมูลไฟล์นั้นโดยไม่ต้องดึงข้อมูลไฟล์เก็บถาวรต้นฉบับทั้งหมด โปรดทราบว่าไฟล์ MODULE.bazel เองนั้นมีความพิเศษ เนื่องจากมีการโฮสต์ไว้ในรีจิสทรีโดยตรง

โดยทั่วไปแล้วผู้ที่ขอใช้ load ใน MODULE.bazel มักจะสนใจกรณีการใช้งานบางกรณี ซึ่งสามารถแก้ไขได้โดยไม่ต้องใช้ load

• การตรวจสอบว่าเวอร์ชันที่ระบุไว้ใน MODULE.bazel สอดคล้องกับข้อมูลเมตาของบิลด์ ที่จัดเก็บไว้ที่อื่น เช่น ในไฟล์ .bzl: คุณสามารถทำได้ โดยใช้วิธี native.module_version ในไฟล์ .bzl ที่โหลดจากไฟล์ BUILD
• การแยกไฟล์ MODULE.bazel ขนาดใหญ่ออกเป็นส่วนที่จัดการได้ โดยเฉพาะอย่างยิ่งสำหรับ monorepo: โมดูลรูทสามารถใช้ include คำสั่งเพื่อแยกไฟล์ MODULE.bazel ออกเป็นหลายส่วน include จะใช้ในโมดูลที่ไม่ใช่รูทไม่ได้ด้วยเหตุผลเดียวกันกับที่เราไม่อนุญาตให้ใช้ load ในไฟล์ MODULE.bazel
• ผู้ใช้ระบบ WORKSPACE เก่าอาจจำได้ว่ามีการประกาศ repo แล้ว load จาก repo นั้นทันทีเพื่อดำเนินการตรรกะที่ซับซ้อน ความสามารถนี้ ถูกแทนที่ด้วยส่วนขยายโมดูล

ฉันระบุช่วง SemVer สำหรับ bazel_dep ได้ไหม

ไม่ได้ ตัวจัดการแพ็กเกจอื่นๆ บางตัว เช่น npm และ Cargo รองรับช่วงเวอร์ชัน (โดยนัยหรือโดยชัดแจ้ง) และมักจะต้องใช้ตัวแก้ปัญหาข้อจำกัด (ทำให้ผู้ใช้คาดการณ์เอาต์พุตได้ยากขึ้น) และทำให้การแก้ปัญหาเวอร์ชันไม่สามารถทำซ้ำได้หากไม่มีไฟล์ล็อก

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

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

ฉันจะรับ bazel_dep เวอร์ชันล่าสุดโดยอัตโนมัติได้ไหม

ผู้ใช้บางรายถามเป็นครั้งคราวว่าสามารถระบุ bazel_dep(name = "foo", version = "latest") เพื่อรับเวอร์ชันล่าสุดของ dep โดยอัตโนมัติได้ไหม ซึ่ง คล้ายกับ คำถามเกี่ยวกับช่วง SemVer และคำตอบก็คือ ไม่ได้

โซลูชันที่แนะนำในที่นี้คือการใช้ระบบอัตโนมัติจัดการเรื่องนี้ เช่น ตัวอย่างเช่น Renovate รองรับ โมดูล Bazel

บางครั้งผู้ใช้ที่ถามคำถามนี้ต้องการวิธีวนซ้ำอย่างรวดเร็วระหว่างการพัฒนาในเครื่อง ซึ่งทำได้โดยใช้ a local_path_override.

ทำไมจึงมี use_repo มากมาย

การใช้งานส่วนขยายโมดูลในไฟล์ MODULE.bazel บางครั้งมาพร้อมกับคำสั่ง use_repo ขนาดใหญ่ ตัวอย่างเช่น การใช้งานส่วนขยาย go_deps จาก gazelle โดยทั่วไปอาจมีลักษณะดังนี้

go_deps = use_extension("@gazelle//:extensions.bzl", "go_deps")
go_deps.from_file(go_mod = "//:go.mod")
use_repo(
    go_deps,
    "com_github_gogo_protobuf",
    "com_github_golang_mock",
    "com_github_golang_protobuf",
    "org_golang_x_net",
    ...  # potentially dozens of lines...
)

คำสั่ง use_repo ที่ยาวอาจดูซ้ำซ้อน เนื่องจากข้อมูลน่าจะอยู่ในไฟล์ go.mod ที่อ้างอิงอยู่แล้ว

เหตุผลที่ Bazel ต้องการคำสั่ง use_repo นี้ก็คือ Bazel จะเรียกใช้ส่วนขยายโมดูลแบบเลซี่ นั่นคือ ระบบจะเรียกใช้ส่วนขยายโมดูลก็ต่อเมื่อมีการสังเกตผลลัพธ์ของส่วนขยายนั้น เนื่องจาก "เอาต์พุต" ของส่วนขยายโมดูลคือคำจำกัดความของ repo ซึ่งหมายความว่าเราจะเรียกใช้ส่วนขยายโมดูลก็ต่อเมื่อมีการขอ repo ที่ส่วนขยายนั้นกำหนดไว้ (เช่น หากมีการสร้างเป้าหมาย @org_golang_x_net//:foo ในตัวอย่างข้างต้น) อย่างไรก็ตาม เราจะไม่ทราบว่าส่วนขยายโมดูลจะกำหนด repo ใดบ้างจนกว่าจะเรียกใช้ส่วนขยายนั้น นี่คือจุดที่คำสั่ง use_repo เข้ามามีบทบาท ผู้ใช้สามารถบอก Bazel ได้ว่าต้องการให้ส่วนขยายสร้าง repo ใดบ้าง แล้ว Bazel จะเรียกใช้ส่วนขยายก็ต่อเมื่อมีการใช้ repo ที่เฉพาะเจาะจงเหล่านี้

ส่วนขยายโมดูลสามารถส่งคืน ออบเจ็กต์ extension_metadata จากฟังก์ชันการใช้งานเพื่อช่วยดูแลคำสั่ง use_repo นี้ ผู้ใช้สามารถเรียกใช้คำสั่ง bazel mod tidy เพื่ออัปเดตคำสั่ง use_repo สำหรับส่วนขยายโมดูลเหล่านี้

การย้ายข้อมูล Bzlmod

ระบบจะประเมิน MODULE.bazel หรือ WORKSPACE ก่อน

เมื่อตั้งค่าทั้ง --enable_bzlmod และ --enable_workspace ก็เป็นเรื่องปกติที่จะสงสัยว่าระบบใดจะได้รับการตรวจสอบก่อน คำตอบสั้นๆ คือระบบจะประเมิน MODULE.bazel (Bzlmod) ก่อน

คำตอบแบบยาวคือ "ระบบใดจะได้รับการประเมินก่อน" ไม่ใช่คำถามที่ถูกต้องที่จะ ถาม แต่คำถามที่ถูกต้องที่จะถามคือในบริบทของ repo ที่มี ชื่อที่ชัดเจน @@foo ชื่อ repo ที่ปรากฏ @bar จะเปลี่ยนเป็นอะไร หรือการแมป repo ของ @@base คืออะไร

ป้ายกำกับที่มีชื่อ repo ที่ปรากฏ (นำหน้าด้วย @ เดียว) อาจอ้างอิงถึงสิ่งต่างๆ ได้โดยขึ้นอยู่กับบริบทที่ใช้แก้ปัญหา เมื่อเห็นป้ายกำกับ @bar//:baz และสงสัยว่าป้ายกำกับนั้นชี้ไปที่ใด คุณต้องค้นหา repo บริบทก่อน เช่น หากป้ายกำกับอยู่ในไฟล์ BUILD ที่อยู่ใน repo @@foo แสดงว่า repo บริบทคือ @@foo

จากนั้น คุณสามารถใช้ตาราง "การมองเห็นที่เก็บข้อมูล" ในคู่มือการย้ายข้อมูลเพื่อ ดูว่าชื่อที่ปรากฏจะเปลี่ยนเป็น repo ใดโดยขึ้นอยู่กับ repo บริบท

• หาก repo บริบทคือ repo หลัก (@@) ให้ทำดังนี้
  1. หาก bar เป็นชื่อ repo ที่ปรากฏซึ่งไฟล์ MODULE.bazel ของโมดูลรูทแนะนำ (ผ่าน bazel_dep,use_repo,module,use_repo_rule อย่างใดอย่างหนึ่ง) @bar จะเปลี่ยนเป็นสิ่งที่ไฟล์ MODULE.bazel นั้นอ้างสิทธิ์
  2. มิเช่นนั้น หาก bar เป็น repo ที่กำหนดไว้ใน WORKSPACE (ซึ่งหมายความว่าชื่อที่ชัดเจนคือ @@bar) แล้ว @bar จะเปลี่ยนเป็น @@bar
  3. มิเช่นนั้น @bar จะเปลี่ยนเป็นบางอย่างเช่น @@[unknown repo 'bar' requested from @@] และสิ่งนี้จะส่งผลให้เกิดข้อผิดพลาดในที่สุด
• หาก repo บริบทเป็น repo ของ Bzlmod-world (นั่นคือ repo ที่สอดคล้องกับโมดูล Bazel ที่ไม่ใช่รูท หรือสร้างขึ้นโดยส่วนขยายโมดูล) repo นั้นจะเห็นเฉพาะ repo อื่นๆ ของ Bzlmod-world เท่านั้น และจะไม่เห็น repo ของ WORKSPACE-world
  • โปรดทราบว่ารวมถึง repo ใดก็ตามที่แนะนำในส่วนขยายโมดูลที่คล้ายกับ non_module_deps ในโมดูลรูท หรือการสร้างอินสแตนซ์ use_repo_rule ในโมดูลรูท
• หาก repo บริบทกำหนดไว้ใน WORKSPACE ให้ทำดังนี้
  1. ก่อนอื่น ให้ตรวจสอบว่าคำจำกัดความของ repo บริบทมีแอตทริบิวต์ repo_mapping ที่สำคัญหรือไม่ หากมี ให้ดูการแมปก่อน (ดังนั้นสำหรับ repo ที่กำหนดไว้ด้วย repo_mapping = {"@bar": "@baz"} เราจะดู at @baz ด้านล่าง)
  2. หาก bar เป็นชื่อ repo ที่ปรากฏซึ่งไฟล์ MODULE.bazel ของโมดูลรูทแนะนำ @bar จะเปลี่ยนเป็นสิ่งที่ไฟล์ MODULE.bazel นั้นอ้างสิทธิ์ (ซึ่งเหมือนกับรายการที่ 1 ในกรณี repo หลัก)
  3. มิเช่นนั้น @bar จะเปลี่ยนเป็น @@bar ซึ่งส่วนใหญ่จะชี้ไปที่ repo bar ที่กำหนดไว้ใน WORKSPACE หากไม่มีการกำหนด repo ดังกล่าว Bazel จะแสดงข้อผิดพลาด

เวอร์ชันที่กระชับมากขึ้น

• repo ของ Bzlmod-world (ไม่รวม repo หลัก) จะเห็นเฉพาะ repo ของ Bzlmod-world เท่านั้น
• repo ของ WORKSPACE-world (รวมถึง repo หลัก) จะเห็นสิ่งที่โมดูลรูทในโลกของ Bzlmod กำหนดไว้ก่อน จากนั้นจึงกลับไปดู repo ของ WORKSPACE-world

โปรดทราบว่าระบบจะถือว่าป้ายกำกับในบรรทัดคำสั่ง Bazel (รวมถึงแฟล็ก Starlark, ค่าแฟล็กประเภทป้ายกำกับ และรูปแบบเป้าหมายการบิลด์/ทดสอบ) มี repo หลักเป็น repo บริบท

อื่นๆ

ฉันจะเตรียมและเรียกใช้บิลด์แบบออฟไลน์ได้อย่างไร

ใช้คำสั่ง bazel fetch เพื่อดึงข้อมูล repo ล่วงหน้า คุณสามารถใช้แฟล็ก --repo (เช่น bazel fetch --repo @foo) เพื่อดึงข้อมูล repo @foo เท่านั้น (แก้ปัญหาในบริบทของ repo หลัก โปรดดู คำถามด้านบน) หรือใช้รูปแบบเป้าหมาย (เช่น bazel fetch @foo//:bar) เพื่อดึงข้อมูลการพึ่งพาแบบทรานซิทีฟทั้งหมดของ @foo//:bar (ซึ่งเทียบเท่ากับ bazel build --nobuild @foo//:bar)

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

หากต้องการดึงข้อมูล repo และ แก้ไข repo เหล่านั้นเพื่อทดสอบในเครื่อง ให้ลองใช้ คำสั่ง bazel vendor

ฉันจะป้องกันไม่ให้บิลด์ของฉันเข้าถึงอินเทอร์เน็ตได้อย่างไร

ต่อไปนี้คือเว็บไซต์บางเว็บไซต์ในอินเทอร์เน็ตที่เข้าถึงได้แบบสาธารณะซึ่งบิลด์ Bazel ทั่วไปต้องอาศัย และสิ่งที่คุณทำได้เพื่อป้องกันตัวเองจากเหตุการณ์ขัดข้องที่อาจเกิดขึ้น โดยเฉพาะอย่างยิ่งในฐานะผู้ใช้ Bazel ระดับองค์กร

• releases.bazel.build: Bazelisk จะดาวน์โหลดไบนารีเวอร์ชันที่เผยแพร่ของ Bazel จากเว็บไซต์นี้ คุณสามารถกำหนดค่า Bazelisk ให้ดาวน์โหลด จากมิเรอร์ภายในของบริษัทแทนได้
• bcr.bazel.build: Bazel จะดูข้อมูลเมตาของโมดูลจาก BCR ระหว่างการแก้ปัญหาโมดูล คุณสามารถมิเรอร์ BCR เองและตั้งค่าแฟล็ก --registry เพื่อนำการพึ่งพาโครงสร้างพื้นฐานการให้บริการ BCR ออก (ดูข้อจำกัดความรับผิดชอบเพื่อดูข้อมูลเพิ่มเติม) หรือคุณสามารถตรวจสอบว่าไฟล์ MODULE.bazel.lock เป็นเวอร์ชันล่าสุด และตั้งค่าเครื่อง CI หรือเครื่องของนักพัฒนาซอฟต์แวร์ด้วยแคชการดาวน์โหลดที่เติมข้อมูลไว้ล่วงหน้า (--repository_cache) หากตั้งค่าอย่างถูกต้อง แคชการดาวน์โหลดจะมีไฟล์รีจิสทรีที่จำเป็นทั้งหมดสำหรับการสร้าง และไฟล์ล็อกจะมีเช็กซัมของไฟล์เหล่านั้น จากนั้น Bazel จะใช้ผลลัพธ์ที่แคชไว้และหลีกเลี่ยงการเข้าถึงอินเทอร์เน็ตโดยสิ้นเชิงระหว่างการแก้ปัญหาโมดูล
• mirror.bazel.build และ github.com: โมดูลจำนวนมากมีไฟล์เก็บถาวรต้นฉบับโฮสต์อยู่ในเว็บไซต์ 2 เว็บไซต์นี้ ลองตั้งค่ามิเรอร์ภายในบริษัทสำหรับไฟล์เก็บถาวรต้นฉบับ และใช้ --downloader_config หรือ --module_mirrors เพื่อชี้ Bazel ไปที่ไฟล์เหล่านั้น หรือแคชการดาวน์โหลดที่เติมข้อมูลไว้ล่วงหน้าตามที่กล่าวถึงในรายการก่อนหน้าจะช่วยให้ Bazel หลีกเลี่ยงการเข้าถึงอินเทอร์เน็ตสำหรับไฟล์เก็บถาวรต้นฉบับได้อย่างสมบูรณ์

ฉันจะใช้พร็อกซี HTTP ได้อย่างไร

Bazel จะใช้ตัวแปรสภาพแวดล้อม http_proxy และ HTTPS_PROXY ที่โปรแกรมอื่นๆ เช่น curl ยอมรับโดยทั่วไป

ฉันจะตั้งค่าให้ Bazel เลือกใช้ IPv6 ในการตั้งค่า IPv4/IPv6 แบบ Dual-stack ได้อย่างไร

ในเครื่องที่ใช้ IPv6 เท่านั้น Bazel จะดาวน์โหลดการพึ่งพาได้โดยไม่มีการเปลี่ยนแปลง อย่างไรก็ตาม ในเครื่องที่ใช้ IPv4/IPv6 แบบ Dual-stack Bazel จะใช้กฎเดียวกันกับ Java โดยเลือกใช้ IPv4 หากเปิดใช้ ในบางสถานการณ์ เช่น เมื่อเครือข่าย IPv4 แก้ปัญหา/เข้าถึงที่อยู่ภายนอกไม่ได้ กรณีนี้อาจทำให้เกิดข้อยกเว้น Network unreachable และการสร้างไม่สำเร็จ ในกรณีเหล่านี้ คุณสามารถลบล้าง ลักษณะการทำงานของ Bazel เพื่อเลือกใช้ IPv6 โดยใช้ java.net.preferIPv6Addresses=true พร็อพเพอร์ตี้ ระบบ ดังนี้

• ใช้ --host_jvm_args=-Djava.net.preferIPv6Addresses=true ตัวเลือกการเริ่มต้น เช่น โดยเพิ่มบรรทัดต่อไปนี้ในไฟล์ .bazelrc

  startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true

• เมื่อเรียกใช้เป้าหมายบิลด์ Java ที่ต้องเชื่อมต่อกับอินเทอร์เน็ต (เช่น สำหรับการทดสอบการผสานรวม) ให้ใช้--jvmopt=-Djava.net.preferIPv6Addresses=true แฟล็กเครื่องมือ เช่น ใส่ในไฟล์ .bazelrc

  build --jvmopt=-Djava.net.preferIPv6Addresses

• หากคุณใช้ rules_jvm_external สำหรับ การแก้ปัญหาเวอร์ชันของทรัพยากร Dependency ให้เพิ่ม -Djava.net.preferIPv6Addresses=true ลงใน COURSIER_OPTS ตัวแปรสภาพแวดล้อม เพื่อ ระบุตัวเลือก JVM สำหรับ Coursier

กฎของ repo สามารถเรียกใช้จากระยะไกลด้วยการดำเนินการจากระยะไกลได้ไหม

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

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

อีกเหตุผลหนึ่งคือ Bazel มักจะต้องใช้ไฟล์ BUILD ในไฟล์เก็บถาวรที่ดาวน์โหลดและแยกไฟล์แล้วเพื่อทำการโหลดและการวิเคราะห์ ซึ่ง จะ ดำเนินการในเครื่อง

เรามีแนวคิดเบื้องต้นในการแก้ปัญหานี้โดยการจินตนาการกฎของ repo ใหม่เป็นกฎการสร้าง ซึ่งจะช่วยให้เรียกใช้กฎจากระยะไกลได้โดยธรรมชาติ แต่ในทางกลับกันก็ทำให้เกิดข้อกังวลด้านสถาปัตยกรรมใหม่ (เช่น คำสั่ง query อาจต้องเรียกใช้การดำเนินการ ซึ่งทำให้การออกแบบซับซ้อนขึ้น)

ดูการสนทนาก่อนหน้านี้เพิ่มเติมเกี่ยวกับหัวข้อนี้ได้ที่ A way to support repositories that need Bazel for being fetched