지속 작업자를 사용하면 빌드 속도를 높일 수 있습니다. 만약 빌드에 시작 비용이 높거나 교차 작업 캐싱의 이점을 누리기 위해서는 자체적인 영구 캐싱을 작업자를 호출하여 이러한 작업을 수행할 수 있습니다.
Bazel 서버는 stdin/stdout를 사용하여 작업자와 통신합니다. 그것은
프로토콜 버퍼나 JSON 문자열의 사용을 지원합니다.
worker 구현은 다음 두 부분으로 구성됩니다.
작업자 생성
영구 작업자는 다음과 같은 몇 가지 요구사항을 충족합니다.
- 다음을 읽습니다.
WorkRequests
stdin에서 추출해야 합니다. - 쓰기
WorkResponses
(
WorkResponse만)stdout에 추가합니다. --persistent_worker플래그를 허용합니다. 래퍼는--persistent_worker명령줄 플래그와 함께 사용하고 다음 경우에만 영구적입니다. 이 플래그가 전달되면 됩니다. 그러지 않으면 원샷 컴파일을 수행하고 종료해야 합니다.
프로그램이 이러한 요건을 충족할 경우, 근로자!
작업 요청
WorkRequest에는 worker에 대한 인수 목록,
작업자가 액세스할 수 있는 입력을 나타내는 경로-다이제스트 쌍 (이것은
이 정보를 캐싱에 사용할 수 있음) 및 요청 ID(0)를
단일 플렉스 작업자에 적합합니다
참고: 프로토콜 버퍼 사양에서는 '스네이크 케이스'를 사용합니다. (request_id),
JSON 프로토콜은 '카멜 표기법'을 사용합니다. (requestId). 이 문서에서는 카멜 표기법을 사용합니다.
은 JSON 예에서 볼 수 있지만 필드에 대해 이야기할 때는
사용할 수 있습니다
{
"arguments" : ["--some_argument"],
"inputs" : [
{ "path": "/path/to/my/file/1", "digest": "fdk3e2ml23d"},
{ "path": "/path/to/my/file/2", "digest": "1fwqd4qdd" }
],
"requestId" : 12
}
선택사항인 verbosity 필드는 추가 디버깅 출력을 요청하는 데 사용할 수 있습니다.
삭제할 수 있습니다 무엇을 어떻게 출력할지는 전적으로 작업자가 결정합니다. 높음
값은 더 상세한 출력을 나타냅니다. --worker_verbose 플래그를
Bazel은 verbosity 필드를 10으로 설정하지만 더 작거나 큰 값을 사용할 수 있습니다.
수동으로 여러 출력을
조정할 수 있습니다
선택사항인 sandbox_dir 필드는
멀티플렉스 샌드박스.
작업 응답
WorkResponse에는 요청 ID, 0 또는 0이 아닌 종료 코드,
처리 또는 실행 중에 발생한 오류를 설명하는 출력 메시지
요청을 처리합니다 작업자는 모든 도구의 stdout 및 stderr를 캡처해야 합니다.
WorkResponse를 통해 보고합니다. stdout에 쓰기
작업자 프로토콜을 방해할 수 있으므로 안전하지 않습니다.
작업자 프로세스의 stderr에 작성하는 것은 안전하지만 결과는 다음과 같습니다.
개별 작업에 귀속되는 대신 작업자별 로그 파일에 수집됩니다.
{
"exitCode" : 1,
"output" : "Action failed with the following message:\nCould not find input
file \"/path/to/my/file/1\"",
"requestId" : 12
}
protobuf의 표준에 따라 모든 필드는 선택사항입니다. 하지만 Bazel은
동일한 요청을 갖도록 WorkRequest 및 상응하는 WorkResponse
ID가 0이 아닌 경우 요청 ID를 지정해야 합니다. 유효한
WorkResponse
{
"requestId" : 12,
}
request_id가 0이면 '단일플렉스'를 나타냅니다. 요청이며, 이 요청이
다른 요청과 동시에 처리할 수 없습니다. 서버에서는
지정된 작업자가 request_id 0만 있는 요청을 수신하거나
request_id가 0보다 큽니다. 싱글플렉스 요청은 순차적으로 전송되어
예를 들어, 서버가 요청을 수신할 때까지 다른 요청을 보내지 않는 경우
반환합니다.
참고
- 각 프로토콜 버퍼는
varint형식의 길이 앞에 옵니다 (자세한 내용은MessageLite.writeDelimitedTo() - JSON 요청 및 응답 앞에는 크기 표시기가 표시되지 않습니다.
- JSON 요청은 protobuf와 동일한 구조를 유지하지만 표준 JSON을 사용하고 모든 필드 이름에는 카멜 표기법을 사용합니다.
- 이전 버전과의 호환성 속성을 동일하게 유지하기 위해 protobuf처럼 JSON 작업자는 이러한 메시지에서 알 수 없는 필드를 허용해야 합니다. 누락된 값에 protobuf 기본값을 사용하세요.
- Bazel은 요청을 protobuf로 저장하고 다음을 사용하여 JSON으로 변환합니다. protobuf의 JSON 형식
취소
작업자는 작업 요청이 완료되기 전에 취소되도록 선택적으로 허용할 수 있습니다.
이는 로컬 요청이 실행되는 동적 실행과 관련하여
더 빠른 원격 실행으로 인해 실행이 정기적으로 중단될 수 있습니다. 허용
취소하려면 supports-worker-cancellation: 1을(를)
execution-requirements 필드 (아래 참고)를 사용하고
--experimental_worker_cancellation 플래그.
취소 요청은 cancel 필드가 설정된 WorkRequest이며
마찬가지로 취소 응답은 was_cancelled가 있는 WorkResponse입니다.
필드가 설정됨). 취소 요청 또는 취소에 있어야 하는 유일한 다른 필드입니다.
응답은 request_id이며 취소할 요청을 나타냅니다. request_id
싱글플렉스 작업자의 경우에는 필드가 0이 되고, 이전의 0이 아닌 request_id가 됩니다.
멀티플렉스 작업자를 위해 WorkRequest를 전송했습니다. 서버에서 취소 요청을 보낼 수 있음
이미 응답한 요청에 대한 응답으로, 이 경우 취소는
요청을 무시해야 합니다.
취소되지 않은 각 WorkRequest 메시지는
취소되지 않은 것입니다. 서버가 취소 요청을 보내면 작업자는
request_id가 설정된 WorkResponse와 was_cancelled로 응답
필드를 true로 설정합니다. 일반적인 WorkResponse 전송도 허용되지만
output 및 exit_code 필드는 무시됩니다.
WorkRequest에 관한 응답이 전송되면 worker는
파일을 찾을 수 있습니다 서버는 자유롭게 파일을 정리하지만,
임시 파일도 포함됩니다.
작업자를 사용하는 규칙 만들기
또한 계정에서 수행할 작업을 생성하는 규칙을 있습니다 작업자를 사용하는 Starlark 규칙을 만드는 것은 다른 규칙 만들기에 대해 자세히 알아보세요.
또한 규칙에는 작업자 자체에 대한 참조가 포함되어야 합니다. 생성하는 작업에 관한 몇 가지 요구사항이 있습니다
worker 참조
작업자를 사용하는 규칙에는 작업자를 참조하는 필드가 포함되어야 합니다.
따라서 \*\_binary 규칙의 인스턴스를 만들어 자체 포드를 정의해야 합니다.
살펴보겠습니다 작업자가 MyWorker.Java라고 하는 경우
관련 규칙:
java_binary(
name = "worker",
srcs = ["MyWorker.Java"],
)
그러면 'worker'라는 라벨을 지정합니다. 그런 다음 작업자를 사용하는 규칙을 정의합니다. 이 규칙은 작업자 바이너리를 나타냅니다
빌드한 작업자 바이너리가 상단에 있는 'work'라는 패키지에 있는 경우 이는 속성 정의일 수 있습니다.
"worker": attr.label(
default = Label("//work:worker"),
executable = True,
cfg = "exec",
)
cfg = "exec"는 작업자가 클러스터에서 실행되도록 빌드되어야 함을 나타냅니다.
대상 플랫폼이 아닌 실행 플랫폼에서 실행되어야 하는 경우 (예: 작업자는
사용할 수도 있습니다.
업무 요구사항
작업자를 사용하는 규칙은 작업자가 수행할 작업을 만듭니다. 이러한 몇 가지 요구사항이 있습니다
"arguments" 필드 이것은 문자열 목록을 가져와서 이는 시작 시 작업자에 전달되는 인수입니다. 마지막 요소는 '인수' list는
flag-file(@-preceded) 인수입니다. 작업자 읽기 WorkRequest별로 지정된 플래그 파일의 인수를 가져옵니다. 내 규칙은 작업자의 비시작 인수를 이 플래그 파일에 쓸 수 있습니다.다음이 포함된 사전을 가져오는 "execution-requirements" 필드
"supports-workers" : "1","supports-multiplex-workers" : "1"또는 둘 다'인수' '실행 요구사항' 필수 입력란입니다. 확인할 수 있습니다 또한 API 역할에서 실행해야 하는 작업은 JSON 작업자는
"requires-worker-protocol" : "json"를 필수 입력란입니다."requires-worker-protocol" : "proto"도 함께 사용할 수 있습니다. proto 작업자에는 필요하지 않지만 이들이 기본값이므로실행 요구사항에서
worker-key-mnemonic를 설정할 수도 있습니다. 이 여러 작업 유형에 실행 파일을 재사용하고 작업을 구별하려고 합니다.작업 과정에서 생성된 임시 파일은 작업자 디렉터리에 있습니다 그러면 샌드박스가 사용 설정됩니다.
'worker'로 규칙 정의 가정 속성의 값을 설정할 수도 있습니다.
'srcs'에 입력을 나타내는 속성인 'output' 속성
출력 및 'args'를 나타냅니다. 작업자를 나타내는 속성
시작 인수의 경우 ctx.actions.run 호출은 다음과 같을 수 있습니다.
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"]
)
다른 예는 다음을 참조하세요. 영구 작업자 구현
예
Bazel 코드베이스는 자바 컴파일러 작업자, 인코더-디코더 아키텍처를 JSON 작업자 예시 Google의 통합 테스트에 사용됩니다.
사용자는 스캐폴딩 올바른 콜백을 전달하여 Java 기반 도구를 작업자로 만들 수 있습니다.
작업자를 사용하는 규칙의 예는 Bazel의 작업자 통합 테스트.
외부 참여자들은 다양한 언어로 근로자를 구현했습니다. 그럼 봐 Bazel 영구 작업자의 Polyglot 구현 다음과 같은 작업을 할 수 있습니다. GitHub에서 더 많은 예제 찾아보기