Worker liên tục có thể giúp bản dựng của bạn nhanh hơn. Nếu có các thao tác lặp lại trong bản dựng có chi phí khởi động cao hoặc sẽ được hưởng lợi từ việc lưu vào bộ nhớ đệm trên nhiều thao tác, bạn nên triển khai worker ổn định của riêng mình để thực hiện các thao tác này.
Máy chủ Bazel giao tiếp với worker bằng stdin/stdout. Máy chủ này hỗ trợ việc sử dụng vùng đệm giao thức hoặc chuỗi JSON.
Quá trình triển khai worker có hai phần:
Tạo worker
Worker liên tục tuân thủ một số yêu cầu:
- Phương thức này đọc WorkRequests từ
stdin. - Phương thức này ghi WorkResponses (và chỉ
WorkResponse) vàostdout. - Phương thức này chấp nhận cờ
--persistent_worker. Trình bao bọc phải nhận ra cờ dòng lệnh--persistent_workervà chỉ tự tạo sự cố định nếu cờ đó được truyền, nếu không phải thực hiện biên dịch một lần và thoát.
Nếu chương trình của bạn tuân thủ các yêu cầu này, thì chương trình đó có thể được dùng làm worker liên tục!
Yêu cầu công việc
WorkRequest chứa danh sách các đối số cho worker, danh sách các cặp hàm băm đường dẫn đại diện cho dữ liệu đầu vào mà worker có thể truy cập (đây không phải là yêu cầu bắt buộc, nhưng bạn có thể sử dụng thông tin này để lưu vào bộ nhớ đệm) và mã yêu cầu là 0 đối với worker singleplex.
LƯU Ý: Mặc dù thông số kỹ thuật của vùng đệm giao thức sử dụng "kiểu viết thường" (request_id), nhưng giao thức JSON sử dụng "kiểu viết hoa chữ cái đầu" (requestId). Tài liệu này sử dụng kiểu viết hoa chữ cái đầu trong các ví dụ về JSON, nhưng sử dụng kiểu viết thường khi nói về trường bất kể giao thức.
{
"arguments" : ["--some_argument"],
"inputs" : [
{ "path": "/path/to/my/file/1", "digest": "fdk3e2ml23d"},
{ "path": "/path/to/my/file/2", "digest": "1fwqd4qdd" }
],
"requestId" : 12
}
Bạn có thể sử dụng trường verbosity không bắt buộc để yêu cầu thêm đầu ra gỡ lỗi từ worker. Điều này hoàn toàn tuỳ thuộc vào worker về nội dung và cách xuất. Giá trị càng cao thì đầu ra càng chi tiết. Việc truyền cờ --worker_verbose đến Bazel sẽ đặt trường verbosity thành 10, nhưng bạn có thể sử dụng các giá trị nhỏ hơn hoặc lớn hơn theo cách thủ công cho nhiều lượng đầu ra.
Trường sandbox_dir không bắt buộc chỉ được các worker hỗ trợ hộp cát đa kênh sử dụng.
Trả lời cho bài tập
WorkResponse chứa mã yêu cầu, mã thoát bằng 0 hoặc khác 0 và một thông báo đầu ra mô tả mọi lỗi gặp phải trong quá trình xử lý hoặc thực thi yêu cầu. Worker phải ghi lại stdout và stderr của bất kỳ công cụ nào mà nó gọi và báo cáo các công cụ đó thông qua WorkResponse. Việc ghi dữ liệu này vào stdout của quy trình worker là không an toàn vì sẽ can thiệp vào giao thức worker.
Việc ghi mã này vào stderr của quy trình worker là an toàn, nhưng kết quả sẽ được thu thập trong tệp nhật ký của từng worker thay vì được gán cho từng hành động riêng lẻ.
{
"exitCode" : 1,
"output" : "Action failed with the following message:\nCould not find input
file \"/path/to/my/file/1\"",
"requestId" : 12
}
Theo tiêu chuẩn của protobuf, tất cả các trường là không bắt buộc. Tuy nhiên, Bazel yêu cầu WorkRequest và WorkResponse tương ứng phải có cùng mã yêu cầu, vì vậy, bạn phải chỉ định mã yêu cầu nếu mã này khác 0. Đây là một WorkResponse hợp lệ.
{
"requestId" : 12,
}
request_id bằng 0 cho biết yêu cầu "singleplex", được dùng khi không thể xử lý yêu cầu này song song với các yêu cầu khác. Máy chủ đảm bảo rằng một worker nhất định sẽ nhận được các yêu cầu chỉ có request_id 0 hoặc chỉ có request_id lớn hơn 0. Các yêu cầu Singleplex được gửi tuần tự, ví dụ: nếu máy chủ không gửi yêu cầu khác cho đến khi nhận được phản hồi (ngoại trừ các yêu cầu huỷ, hãy xem bên dưới).
Lưu ý
- Mỗi vùng đệm giao thức bắt đầu bằng độ dài ở định dạng
varint(xemMessageLite.writeDelimitedTo(). - Yêu cầu và phản hồi JSON không có chỉ báo kích thước ở phía trước.
- Các yêu cầu JSON duy trì cùng một cấu trúc như protobuf, nhưng sử dụng JSON tiêu chuẩn và sử dụng kiểu viết camel case cho tất cả tên trường.
- Để duy trì các thuộc tính tương thích ngược và tương thích với protobuf, trình chạy JSON phải chấp nhận các trường không xác định trong các thông báo này và sử dụng giá trị mặc định của protobuf cho các giá trị bị thiếu.
- Bazel lưu trữ các yêu cầu dưới dạng protobuf và chuyển đổi các yêu cầu đó thành JSON bằng định dạng JSON của protobuf
Huỷ
Worker có thể tuỳ ý cho phép huỷ yêu cầu công việc trước khi hoàn tất.
Điều này đặc biệt hữu ích khi liên kết với quá trình thực thi động, trong đó quá trình thực thi cục bộ thường xuyên bị gián đoạn bởi quá trình thực thi từ xa nhanh hơn. Để cho phép huỷ, hãy thêm supports-worker-cancellation: 1 vào trường execution-requirements (xem bên dưới) và đặt cờ --experimental_worker_cancellation.
Yêu cầu huỷ là một WorkRequest có nhóm trường cancel (và tương tự, phản hồi huỷ là một WorkResponse có nhóm trường was_cancelled). Trường duy nhất khác phải có trong yêu cầu huỷ hoặc phản hồi huỷ là request_id, cho biết yêu cầu nào cần huỷ. Trường request_id sẽ là 0 đối với worker đơn hoặc request_id khác 0 của WorkRequest đã gửi trước đó đối với worker đa năng. Máy chủ có thể gửi yêu cầu huỷ cho các yêu cầu mà worker đã phản hồi. Trong trường hợp này, yêu cầu huỷ phải được bỏ qua.
Bạn phải trả lời chính xác một lần cho mỗi thông báo WorkRequest không huỷ, cho dù thông báo đó có bị huỷ hay không. Sau khi máy chủ gửi yêu cầu huỷ, worker có thể phản hồi bằng WorkResponse trong đó request_id được đặt và trường was_cancelled được đặt thành true. Việc gửi WorkResponse thông thường cũng được chấp nhận, nhưng các trường output và exit_code sẽ bị bỏ qua.
Sau khi gửi phản hồi cho WorkRequest, worker không được chạm vào các tệp trong thư mục đang hoạt động. Máy chủ có thể dọn dẹp các tệp, bao gồm cả tệp tạm thời.
Tạo quy tắc sử dụng worker
Bạn cũng cần tạo một quy tắc để tạo các thao tác cần trình thực thi này thực hiện. Việc tạo quy tắc Starlark sử dụng worker cũng giống như tạo bất kỳ quy tắc nào khác.
Ngoài ra, quy tắc cần chứa một tệp tham chiếu đến chính worker và có một số yêu cầu đối với các hành động mà worker tạo ra.
Tham chiếu đến worker
Quy tắc sử dụng worker cần chứa một trường tham chiếu đến chính worker đó, vì vậy, bạn cần tạo một thực thể của quy tắc \*\_binary để xác định worker. Nếu worker của bạn được gọi là MyWorker.Java, thì đây có thể là quy tắc liên kết:
java_binary(
name = "worker",
srcs = ["MyWorker.Java"],
)
Thao tác này sẽ tạo nhãn "worker", tham chiếu đến tệp nhị phân của worker. Sau đó, bạn sẽ xác định một quy tắc sử dụng worker. Quy tắc này phải xác định một thuộc tính tham chiếu đến tệp nhị phân của worker.
Nếu tệp nhị phân worker bạn đã tạo nằm trong một gói có tên "work", ở cấp cao nhất của bản dựng, thì đây có thể là định nghĩa thuộc tính:
"worker": attr.label(
default = Label("//work:worker"),
executable = True,
cfg = "exec",
)
cfg = "exec" cho biết rằng worker phải được tạo để chạy trên nền tảng thực thi thay vì trên nền tảng mục tiêu (tức là worker được dùng làm công cụ trong quá trình tạo bản dựng).
Yêu cầu về thao tác công việc
Quy tắc sử dụng worker này tạo các thao tác để worker thực hiện. Các thao tác này có một vài yêu cầu.
Trường "arguments" (đối số). Phương thức này lấy một danh sách các chuỗi, tất cả trừ chuỗi cuối cùng là các đối số được truyền đến worker khi khởi động. Phần tử cuối cùng trong danh sách "đối số" là một đối số
flag-file(@ có trước). Worker đọc các đối số từ tệp cờ được chỉ định trên cơ sở mỗi WorkRequest. Quy tắc của bạn có thể ghi các đối số không phải khởi động cho worker vào tệp cờ này.Trường "execution-requirements" (yêu cầu thực thi) sẽ lấy một từ điển chứa
"supports-workers" : "1","supports-multiplex-workers" : "1"hoặc cả hai.Các trường "arguments" và "execution-requirements" là bắt buộc đối với tất cả các thao tác được gửi đến worker. Ngoài ra, các thao tác mà trình chạy JSON sẽ thực thi cần bao gồm
"requires-worker-protocol" : "json"trong trường yêu cầu thực thi."requires-worker-protocol" : "proto"cũng là một yêu cầu thực thi hợp lệ, mặc dù không bắt buộc đối với worker proto, vì chúng là mặc định.Bạn cũng có thể đặt
worker-key-mnemonictrong các yêu cầu thực thi. Điều này có thể hữu ích nếu bạn đang sử dụng lại tệp thực thi cho nhiều loại thao tác và muốn phân biệt các thao tác theo worker này.Các tệp tạm thời được tạo trong quá trình thực hiện hành động phải được lưu vào thư mục của worker. Thao tác này sẽ bật tính năng hộp cát.
Giả sử định nghĩa quy tắc có thuộc tính "worker" được mô tả ở trên, ngoài thuộc tính "srcs" đại diện cho dữ liệu đầu vào, thuộc tính "Output" (đầu ra) đại diện cho kết quả và thuộc tính "args" đại diện cho đối số khởi động worker, lệnh gọi đến ctx.actions.run có thể là:
ctx.actions.run(
inputs=ctx.files.srcs,
outputs=[ctx.outputs.output],
executable=ctx.executable.worker,
mnemonic="someMnemonic",
execution_requirements={
"supports-workers" : "1",
"requires-worker-protocol" : "json"},
arguments=ctx.attr.args + ["@flagfile"]
)
Để biết một ví dụ khác, hãy xem phần Triển khai trình thực thi liên tục.
Ví dụ
Cơ sở mã Bazel sử dụng worker trình biên dịch Java, ngoài worker JSON mẫu được dùng trong các bài kiểm thử tích hợp của chúng ta.
Bạn có thể sử dụng khung công cụ của họ để biến bất kỳ công cụ nào dựa trên Java thành một worker bằng cách truyền vào đúng lệnh gọi lại.
Để xem ví dụ về quy tắc sử dụng một worker, hãy xem kiểm thử tích hợp worker của Bazel.
Các cộng tác viên bên ngoài đã triển khai trình thực thi bằng nhiều ngôn ngữ; hãy xem Cách triển khai Polyglot của trình thực thi bền vững Bazel. Bạn có thể tìm thấy nhiều ví dụ khác trên GitHub!