이 페이지에서는 저장소 규칙을 만드는 방법을 설명하고 확인하세요.
외부 저장소는 WORKSPACE 파일에서만 사용할 수 있고 Bazel의 로드 단계에서 기본 제공되지 않는 작업을 사용 설정하는 규칙입니다. 각 외부 저장소 규칙은 자체 BUILD 파일 및 아티팩트가 있는 자체 워크스페이스를 만듭니다. 서드 파티 라이브러리(예: Maven 패키징된 라이브러리)에 종속되는 데 사용할 수 있지만 Bazel이 실행 중인 호스트에 맞는 BUILD 파일을 생성하는 데도 사용할 수 있습니다.
저장소 규칙 만들기
.bzl 파일에서 repository_rule 함수를 사용하여 새 저장소 규칙을 만들고 전역 변수에 저장합니다.
맞춤 저장소 규칙은 기본 저장소 규칙과 마찬가지로 사용할 수 있습니다. 그것은
필수 name 속성과 빌드 파일에 있는 모든 타겟이 있음
@<name>//package:target로 참조할 수 있습니다. 여기서 <name>는
name 속성
이 규칙은 명시적으로 빌드할 때 또는
지정합니다 이 경우 Bazel은 implementation 함수를 실행합니다. 이
함수는 저장소, 저장소 콘텐츠, BUILD 파일을 만드는 방법을 설명합니다.
속성
속성은 attrs 규칙 인수에 사전으로 전달된 규칙 인수입니다.
저장소 규칙을 정의할 때 속성과 유형이 정의되어 나열됩니다. url 및 sha256 속성을 다음과 같이 정의하는 예
strings:
local_repository = repository_rule(
implementation=_impl,
local=True,
attrs={
"url": attr.string(mandatory=True)
"sha256": attr.string(mandatory=True)
}
)
구현 함수 내에서 속성에 액세스하려면 repository_ctx.attr.<attribute_name>를 사용합니다.
def _impl(repository_ctx):
url = repository_ctx.attr.url
checksum = repository_ctx.attr.sha256
모든 repository_rule에는 빌드와 마찬가지로 암시적으로 정의된 속성이 있습니다.
규칙). 두 가지 암시적 속성은 name (빌드 규칙과 같음)입니다.
repo_mapping입니다. 저장소 규칙의 이름은 repository_ctx.name를 사용하여 액세스할 수 있습니다. repo_mapping의 의미는 네이티브 저장소 규칙 local_repository 및 new_local_repository와 동일합니다.
속성 이름이 _로 시작하면 비공개이며 사용자가 설정할 수 없습니다.
구현 함수
모든 저장소 규칙에는 implementation 함수가 필요합니다. 이 클래스에는 규칙의 실제 로직이 포함되며 로드 단계에서 엄격하게 실행됩니다.
이 함수에는 정확히 하나의 입력 매개변수인 repository_ctx가 있습니다. 함수
는 None 중 하나를 반환하여 주어진
또는 해당 규칙에 대한 매개변수 집합이 포함된 dict를
해당 규칙을 동일한 저장소를 생성하는 재현 가능한 규칙으로 변환합니다. 예를 들어 Git 저장소를 추적하는 규칙의 경우 원래 지정된 플로팅 브랜치 대신 특정 커밋 식별자를 반환하는 것을 의미합니다.
입력 매개변수 repository_ctx는 다음과 같은 작업에 사용할 수 있습니다.
속성 값 및 밀폐되지 않은 함수 (바이너리,
바이너리 실행, 저장소에 파일 만들기, 파일 다운로드
제공합니다. 자세한 내용은 라이브러리를 참고하세요.
컨텍스트입니다 예:
def _impl(repository_ctx):
repository_ctx.symlink(repository_ctx.attr.path, "")
local_repository = repository_rule(
implementation=_impl,
...)
구현 함수는 언제 실행되나요?
저장소의 구현 함수는 Bazel에 예를 들어 다른 타겟 (예: 또는 명령줄에 언급되는지 여부를 확인할 수 있습니다. 이 구현 함수는 이 파일에 저장소를 만들고 있습니다. 이를 '가져오기'라고 합니다. 확인할 수 있습니다
일반 타겟과 달리 저장소가 달라지는 원인이 되는 사항이 변경되더라도 저장소를 반드시 다시 가져오지 않아도 됩니다. 이것은 Bazel이 변경사항을 감지할 수 없거나 모든 빌드에 너무 많은 오버헤드를 초래 (예: 삭제됩니다. 따라서 저장소는 다음 중 하나가 변경되는 경우에만 다시 가져옵니다.
WORKSPACE파일의 저장소 선언에 전달된 매개변수입니다.- 저장소 구현을 구성하는 Starlark 코드입니다.
repository_ctx의getenv()메서드에 전달되거나repository_rule의environ속성으로 선언된 환경 변수의 값입니다. 값 이러한 환경 변수는 명령줄에서--repo_env플래그read(),execute()등에 전달되는 파일의 콘텐츠repository_ctx의 메서드 (예://mypkg:label.txt(mypkg/label.txt아님)bazel sync실행 시
저장소를 다시 가져오는 시점을 제어하는 repository_rule의 두 가지 매개변수는 다음과 같습니다.
configure플래그를 설정하면 다음 위치에서만 저장소를 다시 가져옵니다.--configure매개변수가 전달된 경우bazel sync( 속성을 설정하지 않은 경우 이 명령어로 인해 다시 가져오기가 발생하지 않음)local플래그가 설정된 경우 위의 경우 외에도 Bazel 서버가 다시 시작되거나 저장소 선언에 영향을 미치는 파일(예:WORKSPACE파일 또는 로드하는 파일)이 변경될 때도 저장소가 다시 가져옵니다. 이때 변경사항으로 인해 저장소 선언 또는 코드가 변경되는지 여부는 관계가 없습니다.이 경우 로컬이 아닌 저장소는 다시 가져오지 않습니다. 이러한 저장소는 네트워크와 통신하거나 비용이 많이 든다고 가정되기 때문입니다.
구현 함수 다시 시작
저장소가 생성되는 동안 구현 함수를 다시 시작할 수 있습니다. 요청한 종속 항목이 누락된 경우 가져올 수 있습니다. 이 경우 구현 함수의 실행이 중지되고 누락된 종속 항목이 해결되며 종속 항목이 해결된 후 함수가 다시 실행됩니다. 불필요한 다시 시작(네트워크 액세스를 반복해야 하므로 비용이 많이 듦)을 방지하기 위해 모든 라벨 인수를 기존 파일로 확인할 수 있는 경우 라벨 인수가 미리 가져옵니다. 참고: 실행 중에만 생성된 문자열 또는 라벨의 경로 여전히 재시작될 수 있습니다
외부 저장소의 재가져오기 강제
때로 외부 저장소는
종속 항목이 포함됩니다 예를 들어 소스를 가져오는 저장소가 서드 파티 저장소의 특정 브랜치를 따를 수 있으며, 이 브랜치에서 새 커밋을 사용할 수 있습니다. 이 경우 bazel sync를 호출하여 bazel에 모든 외부 저장소를 무조건 다시 가져오도록 요청할 수 있습니다.
또한 일부 규칙은 로컬 머신을 검사하여
더 이상 유효하지 않을 수 있습니다 여기서 Bazel에게
해당 외부 저장소만 다시 가져옵니다.
repository_rule
정의에 configure 속성이 설정되어 있으므로 bazel sync --configure를 사용하세요.
예
C++ 자동 구성 도구 모음: 저장소 규칙을 사용하여 로컬 C++ 컴파일러, 환경, C++ 컴파일러에서 지원하는 플래그를 찾아 Bazel의 C++ 구성 파일을 자동으로 만듭니다.
Go 저장소 여러
repository_rule를 사용하여 종속 항목 목록을 정의합니다. Google Cloud Storage 버킷이 있습니다rules_jvm_external이 기본적으로 빌드 타겟을 생성하는
@maven라는 외부 저장소 모든 Maven 아티팩트에 관해 API를 제공합니다.