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

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

Nightly · 8.5 · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.7

หน้านี้จะตอบคำถามที่พบบ่อยบางข้อเกี่ยวกับทรัพยากร Dependency ภายนอกใน 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) ซึ่งเป็นแหล่งข้อมูลที่แท้จริงสำหรับ เวอร์ชันโมดูลในระหว่างการแก้ปัญหาการอ้างอิงภายนอกของ Bazel (ดูรีจิสทรี Bazel)

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

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

ฉันควรเพิ่มระดับความเข้ากันได้เมื่อใด

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

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

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

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

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

มี Use Case บางอย่างที่ผู้ใช้ที่ขอ loads ใน MODULE.bazel มักสนใจ และสามารถแก้ไขได้โดยไม่ต้องใช้ loads ดังนี้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

หากต้องการดูเวอร์ชันที่กระชับกว่านี้ ให้ทำดังนี้

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

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

อื่นๆ

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

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

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

หากต้องการดึงข้อมูลที่เก็บ และแก้ไขเพื่อทดสอบในเครื่อง ให้พิจารณาใช้คำสั่ง 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 แบบ 2 สแต็กได้อย่างไร

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

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

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

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

  build --jvmopt=-Djava.net.preferIPv6Addresses

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

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

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

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

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

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

ดูการสนทนาก่อนหน้านี้เพิ่มเติมเกี่ยวกับหัวข้อนี้ได้ที่วิธีสนับสนุนที่เก็บ ที่ต้องใช้ Bazel ในการ ดึงข้อมูล