กฎทั่วไป

กฎ

• อีเมลแทน
• config_setting
• กลุ่มไฟล์
• genquery
• การร่วมสร้าง
• test_suite

ชื่อแทน

alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)

กฎ alias จะสร้างอีกชื่อให้กับกฎนั้นๆ

ชื่อแทนจะใช้ได้เฉพาะสำหรับเป้าหมาย "ทั่วไป" เท่านั้น โดยเฉพาะอย่างยิ่ง package_group และ test_suite จะใช้ชื่อแทนไม่ได้

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

• การทดสอบจะไม่ทำงานหากมีการพูดถึงชื่อแทนในบรรทัดคำสั่ง หากต้องการกำหนดชื่อแทนที่เรียกใช้การทดสอบที่อ้างอิง ให้ใช้กฎ test_suite ที่มีเป้าหมายเดียวในแอตทริบิวต์ tests
• เมื่อกำหนดกลุ่มสภาพแวดล้อม ระบบจะไม่รองรับอีเมลแทนของกฎ environment ซึ่งตัวเลือกบรรทัดคำสั่ง --target_environment ก็ไม่รองรับเช่นกัน

ตัวอย่าง

filegroup(
    name = "data",
    srcs = ["data.txt"],
)

alias(
    name = "other",
    actual = ":data",
)

อาร์กิวเมนต์

config_setting

config_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)

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

ตัวอย่าง

รายการต่อไปนี้ตรงกับบิลด์ใดๆ ที่ตั้งค่า --compilation_mode=opt หรือ -c opt (อย่างชัดแจ้งที่บรรทัดคำสั่งหรือโดยนัยจากไฟล์ .bazelrc)

  config_setting(
      name = "simple",
      values = {"compilation_mode": "opt"}
  )
  

รายการต่อไปนี้ตรงกับบิลด์ใดก็ตามที่กำหนดเป้าหมายเป็น ARM และใช้คำจำกัดความที่กำหนดเอง FOO=bar (เช่น bazel build --cpu=arm --define FOO=bar ...)

  config_setting(
      name = "two_conditions",
      values = {
          "cpu": "arm",
          "define": "FOO=bar"
      }
  )
  

รายการต่อไปนี้ตรงกับบิลด์ใดๆ ที่ตั้งค่าแฟล็กที่ผู้ใช้กำหนด --//custom_flags:foo=1 (อย่างชัดแจ้งในบรรทัดคำสั่งหรือโดยนัยจากไฟล์ .bazelrc)

  config_setting(
      name = "my_custom_flag_is_set",
      flag_values = { "//custom_flags:foo": "1" },
  )
  

รายการต่อไปนี้ตรงกับบิลด์ทั้งหมดที่กำหนดเป้าหมายแพลตฟอร์มด้วยสถาปัตยกรรม x86_64 และ glibc เวอร์ชัน 2.25 โดยมีสมมติฐานว่ามี constraint_value ที่มีป้ายกำกับ //example:glibc_2_25 โปรดทราบว่าแพลตฟอร์มจะยังคงจับคู่กันหากกำหนดค่าข้อจำกัดเพิ่มเติมที่นอกเหนือจาก 2 ค่านี้

  config_setting(
      name = "64bit_glibc_2_25",
      constraint_values = [
          "@platforms//cpu:x86_64",
          "//example:glibc_2_25",
      ]
  )
  

Notes

• ดูการเลือกสำหรับสิ่งที่จะเกิดขึ้นเมื่อ config_setting หลายรายการตรงกับสถานะการกำหนดค่าปัจจุบัน
• สำหรับแฟล็กที่รองรับแบบฟอร์มชวเลข (เช่น --compilation_mode กับ -c) คำจำกัดความ values ต้องใช้แบบฟอร์มแบบเต็ม ซึ่งจะจับคู่คำขอโดยอัตโนมัติโดยใช้รูปแบบใดรูปแบบหนึ่ง
• หากแฟล็กมีค่าหลายค่า (เช่น --copt=-Da --copt=-Db หรือ แฟล็ก Starlark ที่เป็นประเภทรายการ) values = { "flag": "a" } จะจับคู่หาก "a" ปรากฏทุกที่ในรายการจริง

  values = { "myflag": "a,b" } ทำงานในลักษณะเดียวกัน: จะจับคู่กับ --myflag=a --myflag=b, --myflag=a --myflag=b --myflag=c, --myflag=a,b และ --myflag=c,b,a ความหมายที่แน่นอนจะแตกต่างกันไปในแต่ละแฟล็ก เช่น --copt ไม่รองรับหลายค่าในอินสแตนซ์เดียวกัน: --copt=a,b จะสร้าง ["a,b"] ในขณะที่ --copt=a --copt=b สร้าง ["a", "b"] (เพื่อให้ values = { "copt": "a,b" } ตรงกับค่าแรก แต่ไม่ใช่ค่าหลัง) แต่ --ios_multi_cpus (สำหรับกฎของ Apple) ทำ -ios_multi_cpus=a,b และ ios_multi_cpus=a --ios_multi_cpus=b ทั้ง 2 รายการทำให้เกิด ["a", "b"] โปรดตรวจสอบคําจํากัดความของการแจ้งว่าไม่เหมาะสมและทดสอบเงื่อนไขโดยละเอียดเพื่อยืนยันความคาดหวังที่แน่นอน

• หากต้องการกำหนดเงื่อนไขที่ไม่ได้สร้างโมเดลโดยแฟล็กบิลด์ในตัว ให้ใช้ แฟล็กที่ Starlark กำหนด นอกจากนี้ คุณยังใช้ --define ได้ด้วย แต่วิธีนี้ให้การสนับสนุนที่ไม่รัดกุมกว่า เราจึงไม่แนะนำ ดูการสนทนาเพิ่มเติมที่นี่
• หลีกเลี่ยงการใช้คำจำกัดความ config_setting ที่ซ้ำกันในแพ็กเกจที่ต่างกัน แต่ให้อ้างอิง config_setting ทั่วไปที่กำหนดไว้ในแพ็กเกจ Canonical แทน
• คุณใช้ values, define_values และ constraint_values ร่วมกับชุดค่าผสมใดก็ได้ใน config_setting เดียวกัน แต่ต้องตั้งค่าอย่างน้อย 1 รายการสำหรับ config_setting ที่ระบุ

อาร์กิวเมนต์

            config_setting(
                name = "a_and_b",
                values = {
                    "define": "a=1",
                    "define": "b=2",
                })
          

            config_setting(
                name = "a_and_b",
                define_values = {
                    "a": "1",
                    "b": "2",
                })
          

กลุ่มไฟล์

filegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)

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

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

ตัวอย่าง

หากต้องการสร้าง filegroup ที่ประกอบด้วยไฟล์ต้นฉบับ 2 ไฟล์ ให้ทำ

filegroup(
    name = "mygroup",
    srcs = [
        "a_file.txt",
        "some/subdirectory/another_file.txt",
    ],
)

หรือใช้ glob เพื่อค้นหาไดเรกทอรี testdata:

filegroup(
    name = "exported_testdata",
    srcs = glob([
        "testdata/*.dat",
        "testdata/logs/**/*.log",
    ]),
)

หากต้องการใช้คําจํากัดความเหล่านี้ ให้อ้างอิง filegroup พร้อมป้ายกํากับจากกฎใดก็ได้:

cc_library(
    name = "my_library",
    srcs = ["foo.cc"],
    data = [
        "//my_package:exported_testdata",
        "//my_package:mygroup",
    ],
)

อาร์กิวเมนต์

Genquery

genquery(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, expression, features, licenses, opts, restricted_to, scope, strict, tags, target_compatible_with, testonly, visibility)

genquery() เรียกใช้การค้นหาที่ระบุในภาษาการค้นหา Blaze และถ่ายโอนผลลัพธ์ไปยังไฟล์

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

ความแตกต่างเพียงอย่างเดียวระหว่างคำค้นหาที่อนุญาตที่นี่และในบรรทัดคำสั่งคือไม่อนุญาตให้ใช้คำค้นหาที่มีข้อกำหนดเป้าหมายไวลด์การ์ด (เช่น //pkg:* หรือ //pkg:all) ที่นี่ สาเหตุคือ 2 ประการแรก เนื่องจาก genquery ต้องระบุขอบเขตเพื่อป้องกันไม่ให้เป้าหมายที่อยู่นอกการปิดการค้นหาแบบชั่วคราวเพื่อให้มีผลต่อเอาต์พุต และข้อที่ 2 เนื่องจากไฟล์ BUILD ไม่รองรับทรัพยากร Dependency ของไวลด์การ์ด (เช่น ไม่อนุญาต deps=["//a/..."])

เอาต์พุตของ genquery จะเรียงลำดับโดยใช้ --order_output=full เพื่อบังคับใช้เอาต์พุตตามเชิงกำหนด

ชื่อของไฟล์เอาต์พุตคือชื่อของกฎ

ตัวอย่าง

ตัวอย่างนี้เขียนรายการป้ายกำกับในการปิดทางอ้อมของเป้าหมายที่ระบุไปยังไฟล์

genquery(
    name = "kiwi-deps",
    expression = "deps(//kiwi:kiwi_lib)",
    scope = ["//kiwi:kiwi_lib"],
)

อาร์กิวเมนต์

การร่วมเพศ

genrule(name, srcs, outs, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exec_tools, executable, features, licenses, local, message, output_licenses, output_to_bindir, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)

genrule จะสร้างไฟล์อย่างน้อย 1 ไฟล์โดยใช้คำสั่ง Bash ที่ผู้ใช้กำหนด

Genrules เป็นกฎบิลด์ทั่วไปที่คุณใช้ได้หากไม่มีกฎที่เจาะจงสําหรับงาน ตัวอย่างเช่น คุณเรียกใช้ 1 บรรทัดของ Bash ได้ แต่หากต้องการคอมไพล์ไฟล์ C++ ให้ยึดตามกฎ cc_* ที่มีอยู่ เนื่องจากการดำเนินการที่ยุ่งยากทั้งหมดได้ดำเนินไปเรียบร้อยแล้ว

อย่าใช้ GenRule สำหรับการทดสอบ มีค่าตอบแทนพิเศษสำหรับการทดสอบและผลการทดสอบ รวมถึงนโยบายการแคชและตัวแปรสภาพแวดล้อม โดยทั่วไปแล้ว การทดสอบจะต้องดำเนินการหลังจากที่บิลด์เสร็จสมบูรณ์และในสถาปัตยกรรมเป้าหมาย ในขณะที่ Genrules จะทำงานระหว่างบิลด์และในสถาปัตยกรรมโฮสต์ (ทั้ง 2 แบบอาจแตกต่างกัน) หากต้องการกฎการทดสอบจุดประสงค์ทั่วไป ให้ใช้ sh_test

การพิจารณาการคอมไพล์ข้ามข้อมูล

ดูข้อมูลเพิ่มเติมเกี่ยวกับการคอมไพล์ข้ามได้ในคู่มือผู้ใช้

แม้ว่า Genrules จะทำงานระหว่างบิลด์ แต่เอาต์พุตของโมเดลมักจะใช้หลังจากบิลด์สำหรับการติดตั้งใช้งานหรือทดสอบ ลองพิจารณาตัวอย่างการคอมไพล์โค้ด C สำหรับไมโครคอนโทรลเลอร์ โดยคอมไพเลอร์จะยอมรับซอร์สไฟล์ C และสร้างโค้ดที่ทำงานบนไมโครคอนโทรลเลอร์ แน่นอนว่าโค้ดที่สร้างขึ้นจะไม่สามารถเรียกใช้บน CPU ที่ใช้ในการสร้างโค้ดได้ แต่ตัวคอมไพเลอร์ C (หากคอมไพล์จากซอร์สโค้ด) เองจะต้องทำ

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

สำหรับ Genrules ระบบบิลด์จะดูแลให้มีการสร้างทรัพยากร Dependency อย่างเหมาะสม โดยสร้าง srcs (หากจำเป็น) สำหรับการกำหนดค่าเป้าหมาย, tools สร้างขึ้นสำหรับการกำหนดค่าโฮสต์ และถือว่าเอาต์พุตสำหรับการกำหนดค่าเป้าหมาย และยังมี ตัวแปร "Make" ที่คำสั่ง GenRule ส่งผ่านไปยังเครื่องมือที่เกี่ยวข้องได้

กฎเกณฑ์ต้องไม่ได้กำหนดแอตทริบิวต์ deps โดยกฎอื่นๆ ที่มีมาในตัวจะใช้ข้อมูลเมตาที่อิงตามภาษาซึ่งส่งผ่านระหว่างกฎต่างๆ เพื่อกำหนดวิธีจัดการกฎที่ขึ้นต่อกันโดยอัตโนมัติ แต่ระบบอัตโนมัติระดับนี้ไม่สามารถทำได้สำหรับ Genrules Genrules จะทำงานที่ระดับไฟล์และ Runfile เท่านั้น

กรณีพิเศษ

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

เครื่องมือ JDK และ C++: หากต้องการใช้เครื่องมือจาก JDK หรือชุดคอมไพเลอร์ C++ ระบบบิลด์จะมีชุดตัวแปรที่ใช้ได้ ดูรายละเอียดได้ที่ตัวแปร"ผู้ผลิต"

สภาพแวดล้อมการสร้างกฎ

คำสั่ง genRule จะทำงานโดยเชลล์ Bash ที่กำหนดค่าให้ล้มเหลวเมื่อคำสั่งหรือไปป์ไลน์ล้มเหลวโดยใช้ set -e -o pipefail

เครื่องมือสร้างบิลด์จะเรียกใช้คำสั่ง Bash ในสภาพแวดล้อมกระบวนการที่ปลอดภัยซึ่งกำหนดเฉพาะตัวแปรหลัก เช่น PATH, PWD, TMPDIR และอื่นๆ ระบบจะไม่ส่งตัวแปรส่วนใหญ่ที่กำหนดในสภาพแวดล้อม Shell ของผู้ใช้ไปยังคำสั่งของ genRule เพื่อให้มั่นใจว่าบิลด์จะทำซ้ำได้ แต่ Bazel (แต่ไม่ใช่ Blaze) จะส่งผ่านค่าตัวแปรสภาพแวดล้อม PATH ของผู้ใช้ การเปลี่ยนแปลงค่าของ PATH จะทำให้ Bazel เรียกใช้คำสั่งอีกครั้งในบิลด์ถัดไป

คำสั่ง genRule ไม่ควรเข้าถึงเครือข่าย ยกเว้นเพื่อเชื่อมต่อกระบวนการที่เป็นรายการย่อยของคำสั่งเอง แม้ว่าขณะนี้ยังไม่ได้บังคับใช้ก็ตาม

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

คำแนะนำทั่วไป

• ตรวจสอบว่าเครื่องมือที่เรียกใช้โดยกฎเกณฑ์เป็นแบบกำหนดและไม่แบ่งแยก เครื่องมือดังกล่าวไม่ควรเขียนการประทับเวลาลงในเอาต์พุต และควรใช้การจัดลำดับที่เสถียรสำหรับชุดและแผนที่ ตลอดจนเขียนเฉพาะเส้นทางไฟล์สัมพัทธ์ไปยังเอาต์พุต ไม่ใช่เส้นทางสัมบูรณ์ การไม่ปฏิบัติตามกฎนี้จะทำให้เกิดลักษณะการทำงานที่ไม่คาดคิด (Bazel ไม่ได้สร้างกฎเกณฑ์ขึ้นมาใหม่แบบที่คิดไว้) และจะทำให้ประสิทธิภาพของแคชลดลง
• ใช้ $(location) ให้ครอบคลุมสำหรับเอาต์พุต เครื่องมือ และแหล่งที่มา เนื่องจากการแยกไฟล์เอาต์พุตสำหรับการกำหนดค่าที่แตกต่างกัน ทำให้ Genrules ไม่ต้องใช้เส้นทางแบบฮาร์ดโค้ดและ/หรือเส้นทางแบบสัมบูรณ์
• ควรเขียนมาโคร Starlark ทั่วไปในกรณีที่มีการใช้กฎพื้นฐานเดียวกันหรือคล้ายกันมากในหลายๆ ที่ หากรูปแบบพันธุกรรมซับซ้อน ให้พิจารณานำมาใช้ในสคริปต์หรือใช้เป็นกฎของ Starlark ซึ่งจะช่วยให้อ่านง่ายขึ้นและง่ายขึ้น
• ตรวจสอบว่ารหัสการออกนั้นบ่งบอกถึงความสำเร็จหรือความล้มเหลวของการสร้างกฎอย่างถูกต้อง
• อย่าเขียนข้อความให้ข้อมูลไปยัง stdout หรือ stderr แม้ว่าจะมีประโยชน์สําหรับการแก้ไขข้อบกพร่อง แต่ก็อาจทำให้เกิดสัญญาณรบกวนได้ง่ายๆ การสร้างกฎที่ประสบความสำเร็จไม่ควรเงียบ ในทางกลับกัน การเกิดกฎเกณฑ์ล้มเหลวควรส่งข้อความแสดงข้อผิดพลาดที่ดี
• $$ evaluates to a $, a literal dollar-sign, so in order to invoke a shell command containing dollar-signs such as ls $(dirname $x), one must escape it thus: ls $$(dirname $$x).
• หลีกเลี่ยงการสร้างลิงก์สัญลักษณ์และไดเรกทอรี Bazel จะไม่คัดลอกโครงสร้างไดเรกทอรี/Symlink ที่สร้างโดย genrules และการตรวจสอบทรัพยากร Dependency ของไดเรกทอรีจะไม่เกิดขึ้นจริง
• เมื่ออ้างอิง GenRule ในกฎอื่นๆ คุณจะใช้ป้ายกำกับของ GenRule หรือป้ายกำกับของไฟล์เอาต์พุตแต่ละไฟล์ได้ บางครั้งวิธีหนึ่งเป็นวิธีที่อ่านได้ง่ายกว่า และบางครั้งอาจเป็นการอ้างอิงผลลัพธ์ตามชื่อใน srcs ของกฎการบริโภคจะหลีกเลี่ยงการเลือกเอาต์พุตอื่นๆ ของการสร้างกฎโดยไม่ได้ตั้งใจ แต่อาจน่าเบื่อหาก GenRule สร้างเอาต์พุตจำนวนมาก

ตัวอย่าง

ตัวอย่างนี้สร้าง foo.h ไม่มีแหล่งที่มา เนื่องจากคำสั่งไม่ได้รับอินพุตใดๆ "ไบนารี" ที่เรียกใช้โดยคำสั่งเป็นสคริปต์ Perl ในแพ็กเกจเดียวกันกับ GenRule

genrule(
    name = "foo",
    srcs = [],
    outs = ["foo.h"],
    cmd = "./$(location create_foo.pl) > \"$@\"",
    tools = ["create_foo.pl"],
)

ตัวอย่างต่อไปนี้แสดงวิธีใช้ filegroup และเอาต์พุตของ genrule อีกรายการ โปรดทราบว่าการใช้ $(SRCS) แทนคำสั่ง $(location) อย่างชัดแจ้งก็ใช้ได้เช่นกัน ตัวอย่างนี้ใช้คำสั่งหลังเพื่อการสาธิต

genrule(
    name = "concat_all_files",
    srcs = [
        "//some:files",  # a filegroup with multiple files in it ==> $(locations)
        "//other:gen",   # a genrule with a single output ==> $(location)
    ],
    outs = ["concatenated.txt"],
    cmd = "cat $(locations //some:files) $(location //other:gen) > $@",
)

อาร์กิวเมนต์

test_suite

test_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)

test_suite จะกำหนดชุดการทดสอบที่มนุษย์ถือว่า "มีประโยชน์" วิธีนี้ช่วยให้โปรเจ็กต์กำหนดชุดการทดสอบได้ เช่น "การทดสอบที่คุณต้องทำก่อนเช็คอิน" "การทดสอบความเครียดของโปรเจ็กต์" หรือ "การทดสอบย่อยทั้งหมด" คำสั่ง blaze test จะดำเนินการตามการจัดระเบียบประเภทนี้ กล่าวคือ สำหรับการเรียกใช้อย่าง blaze test //some/test:suite ก่อนอื่น Blaze จะแจกแจงเป้าหมายการทดสอบทั้งหมดที่รวมอยู่ในเป้าหมาย //some/test:suite (เราเรียกสิ่งนี้ว่า "test_suite การขยาย") จากนั้น Blaze จะสร้างและทดสอบเป้าหมายเหล่านั้น

ตัวอย่าง

ชุดทดสอบสำหรับทำการทดสอบขนาดเล็กทั้งหมดในแพ็กเกจปัจจุบัน

test_suite(
    name = "small_tests",
    tags = ["small"],
)

ชุดทดสอบที่เรียกใช้ชุดการทดสอบที่ระบุ

test_suite(
    name = "smoke_tests",
    tests = [
        "system_unittest",
        "public_api_unittest",
    ],
)

ชุดทดสอบที่จะทำการทดสอบทั้งหมดในแพ็กเกจปัจจุบันซึ่งไม่ปะติดปะต่อ

test_suite(
    name = "non_flaky_test",
    tags = ["-flaky"],
)

อาร์กิวเมนต์