การใช้มาโครเพื่อสร้างคำกริยาที่กำหนดเอง

การโต้ตอบกับ Bazel ในแต่ละวันจะดำเนินการผ่านคำสั่ง 3 คำสั่งหลักๆ ดังนี้ build, test และ run แต่บางครั้งคุณอาจรู้สึกว่าเครื่องมือเหล่านี้มีข้อจำกัด เช่น คุณอาจต้องการพุชแพ็กเกจไปยังที่เก็บ เผยแพร่เอกสารประกอบสำหรับผู้ใช้ปลายทาง หรือทำให้แอปพลิเคชันใช้งานได้ด้วย Kubernetes แต่ Bazel ไม่มีคำสั่ง publish หรือ deploy แล้วการดำเนินการเหล่านี้จะใส่ไว้ตรงไหน

คำสั่งเรียกใช้ Bazel

การมุ่งเน้นของ Bazel ในด้านความต่อเนื่อง การทำซ้ำ และส่วนเพิ่มทำให้คำสั่ง build และ test ไม่มีประโยชน์ต่องานด้านบน การดำเนินการเหล่านี้อาจทำงานในแซนด์บ็อกซ์ที่มีสิทธิ์เข้าถึงเครือข่ายแบบจํากัด และไม่มีการรับประกันว่าจะทําซ้ำกับ bazel build ทุกรายการ

แต่ให้ใช้ bazel run แทน ซึ่งเป็นเครื่องมือที่ทำงานหนักสำหรับงานที่คุณต้องการให้มีผลข้างเคียง ผู้ใช้ Bazel คุ้นเคยกับกฎที่สร้างไฟล์ปฏิบัติการ และผู้เขียนกฎสามารถทําตามชุดรูปแบบทั่วไปเพื่อขยายการทำงานนี้ไปยัง "คํากริยาที่กําหนดเอง"

เวอร์ชันที่ใช้งานจริง: rules_k8s

ตัวอย่างเช่น ลองพิจารณา rules_k8s ซึ่งเป็นกฎ Kubernetes สําหรับ Bazel สมมติว่าคุณมีเป้าหมายต่อไปนี้

# BUILD file in //application/k8s
k8s_object(
    name = "staging",
    kind = "deployment",
    cluster = "testing",
    template = "deployment.yaml",
)

กฎ k8s_object จะสร้างไฟล์ Kubernetes YAML มาตรฐานเมื่อมีการใช้ bazel build ในเป้าหมาย staging อย่างไรก็ตาม มาโคร k8s_object จะสร้างเป้าหมายเพิ่มเติมที่มีชื่ออย่างเช่น staging.apply และ :staging.delete ด้วย คำสั่งเหล่านี้จะสร้างสคริปต์เพื่อดำเนินการเหล่านั้น และเมื่อเรียกใช้ด้วย bazel run staging.apply คำสั่งเหล่านี้จะทำงานเหมือนคำสั่ง bazel k8s-apply หรือ bazel k8s-delete ของเราเอง

อีกตัวอย่างหนึ่ง: ts_api_guardian_test

รูปแบบนี้สามารถดูในโปรเจ็กต์ Angular ได้ด้วย มาโคร ts_api_guardian_test จะสร้างเป้าหมาย 2 รายการ รายการแรกคือเป้าหมาย nodejs_test มาตรฐานซึ่งจะเปรียบเทียบเอาต์พุตที่สร้างขึ้นบางส่วนกับไฟล์ "โกลด์" (นั่นคือไฟล์ที่มีเอาต์พุตที่คาดไว้) ซึ่งจะสร้างและเรียกใช้ได้ด้วยการเรียกใช้ bazel test ปกติ ใน angular-cli คุณสามารถเรียกใช้เป้าหมายดังกล่าวด้วย bazel test //etc/api:angular_devkit_core_api

เมื่อเวลาผ่านไป คุณอาจต้องอัปเดตไฟล์ทองคำนี้ด้วยเหตุผลที่เหมาะสม การอัปเดตด้วยตนเองนั้นน่าเบื่อและอาจเกิดข้อผิดพลาดได้ ดังนั้นมาโครนี้จึงมีเป้าหมาย nodejs_binary ที่อัปเดตไฟล์โกลด์แทนการเปรียบเทียบกับไฟล์โกลด์ กล่าวโดยสรุปคือ คุณเขียนสคริปต์ทดสอบเดียวกันให้ทำงานในโหมด "ยืนยัน" หรือ "ยอมรับ" ได้ โดยขึ้นอยู่กับวิธีเรียกใช้ การดำเนินการนี้เป็นไปตามรูปแบบเดียวกับที่คุณได้เรียนรู้ไปแล้ว นั่นคือไม่มีคำสั่ง bazel test-accept ในตัว แต่คุณก็ใช้ bazel run //etc/api:angular_devkit_core_api.accept เพื่อสร้างผลลัพธ์เดียวกันได้

รูปแบบนี้อาจใช้ได้ผลดีมาก และค่อนข้างจะเป็นรูปแบบที่พบได้บ่อยเมื่อคุณเรียนรู้ที่จะจดจำ

การปรับกฎของคุณเอง

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

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

_sphinx_site = rule(
     implementation = _sphinx_impl,
     attrs = {"srcs": attr.label_list(allow_files = [".rst"])},
)

ต่อไป ให้พิจารณากฎอย่างเช่นด้านล่าง ซึ่งจะสร้างสคริปต์ที่เมื่อเรียกใช้แล้วจะเผยแพร่หน้าที่สร้างขึ้น

_sphinx_publisher = rule(
    implementation = _publish_impl,
    attrs = {
        "site": attr.label(),
        "_publisher": attr.label(
            default = "//internal/sphinx:publisher",
            executable = True,
        ),
    },
    executable = True,
)

สุดท้าย ให้กําหนดมาโครต่อไปนี้เพื่อสร้างเป้าหมายสําหรับทั้ง 2 กฎข้างต้นร่วมกัน

def sphinx_site(name, srcs = [], **kwargs):
    # This creates the primary target, producing the Sphinx-generated HTML.
    _sphinx_site(name = name, srcs = srcs, **kwargs)
    # This creates the secondary target, which produces a script for publishing
    # the site generated above.
    _sphinx_publisher(name = "%s.publish" % name, site = name, **kwargs)

ในไฟล์ BUILD ให้ใช้มาโครราวกับว่าเพิ่งสร้างเป้าหมายหลัก

sphinx_site(
    name = "docs",
    srcs = ["index.md", "providers.md"],
)

ในตัวอย่างนี้ ระบบจะสร้างเป้าหมาย "docs" เหมือนกับว่ามาโครเป็นกฎ Bazel มาตรฐานรายการเดียว เมื่อสร้างแล้ว กฎจะสร้างการกำหนดค่าบางอย่าง และเรียกใช้ Sphinx เพื่อสร้างเว็บไซต์ HTML ซึ่งพร้อมสำหรับการตรวจสอบด้วยตนเอง อย่างไรก็ตาม ระบบจะสร้างเป้าหมาย "docs.publish" เพิ่มเติมด้วย ซึ่งจะสร้างสคริปต์สําหรับเผยแพร่เว็บไซต์ เมื่อตรวจสอบเอาต์พุตของเป้าหมายหลักแล้ว คุณจะใช้ bazel run :docs.publish เพื่อเผยแพร่เอาต์พุตดังกล่าวต่อสาธารณะได้ เช่นเดียวกับคำสั่ง bazel publish จินตนาการ

การใช้งาน_sphinx_publisherกฎอาจมีลักษณะเป็นอย่างไร การดำเนินการเช่นนี้มักจะเขียนสคริปต์เชลล์ Launcher โดยปกติแล้ววิธีนี้เกี่ยวข้องกับการใช้ ctx.actions.expand_template เพื่อเขียนเชลล์สคริปต์อย่างง่าย ซึ่งในกรณีนี้คือการเรียกใช้ไบนารีของผู้เผยแพร่โฆษณาพร้อมเส้นทางไปยังเอาต์พุตของเป้าหมายหลัก วิธีนี้ช่วยให้ผู้เผยแพร่โฆษณาใช้การนําไปใช้แบบทั่วไปได้ กฎ _sphinx_site จะสร้างได้แค่ HTML และสคริปต์เล็กๆ นี้เป็นสิ่งที่จําเป็นทั้งหมดในการรวมทั้งสองเข้าด้วยกัน

ใน rules_k8s .apply ทําสิ่งต่อไปนี้จริงๆ expand_template เขียนสคริปต์ Bash ที่เรียบง่ายมาก โดยอิงตาม apply.sh.tpl ซึ่งเรียกใช้ kubectl ด้วยเอาต์พุตของเป้าหมายหลัก จากนั้นจะสร้างและเรียกใช้สคริปต์นี้ด้วย bazel run :staging.apply ได้ ซึ่งจะแสดงคําสั่ง k8s-apply สําหรับเป้าหมาย k8s_object อย่างมีประสิทธิภาพ