이 페이지에서는 저장소 규칙을 정의하는 방법을 설명하고 자세한 내용을 위한 예를 제공합니다.
외부 저장소는 Bazel 빌드에서 사용할 수 있는 소스 파일이 포함된 디렉터리 트리로,
해당 저장소 규칙을 실행하여 주문형으로 생성됩니다. 저장소는 다양한 방법으로 정의할 수 있지만 궁극적으로 각 저장소는 빌드 규칙을 호출하여 빌드 타겟을 정의하는 것과 마찬가지로 저장소 규칙을 호출하여 정의됩니다. 이를 사용하여 서드 파티 라이브러리 (예: Maven 패키지 라이브러리)에 종속될 뿐만 아니라 Bazel이 실행되는 호스트에 특정한 BUILD 파일을 생성할 수도 있습니다.
저장소 규칙 정의
.bzl 파일에서
repository_rule 함수를 사용하여
새 저장소 규칙을 정의하고 전역 변수에 저장합니다. 저장소 규칙이 정의되면 함수로 호출하여 저장소를 정의할 수 있습니다. 이 호출은 일반적으로
모듈 확장 프로그램 구현
함수 내부에서 실행됩니다.
저장소 규칙 정의의 두 가지 주요 구성요소는 속성 스키마와 구현 함수입니다. 속성 스키마는 저장소 규칙 호출에 전달되는 속성의 이름과 유형을 결정하고, 저장소를 가져와야 할 때 구현 함수가 실행됩니다.
속성
속성은 저장소 규칙 호출에 전달되는 인수입니다. 저장소 규칙에서 허용되는 속성의 스키마는 repository_rule 호출로 저장소 규칙이 정의될 때 attrs 인수를 사용하여 지정됩니다. url 및 sha256 속성을 문자열로 정의하는 예는 다음과 같습니다.
http_archive = repository_rule(
implementation=_impl,
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이 있습니다. 이는 다소 마법처럼 동작하는 문자열 속성입니다. 저장소 규칙 호출의 입력으로 지정되면 명백한 저장소 이름을 가져오지만 repository_ctx.attr.name을 사용하여 저장소 규칙의 구현 함수에서 읽으면 정식 저장소 이름을 반환합니다.
구현 함수
모든 저장소 규칙에는 implementation 함수가 필요합니다. 여기에는 규칙의 실제 로직이 포함되어 있으며 로드 단계에서 엄격하게 실행됩니다.
함수에는 입력 매개변수가 정확히 하나인 repository_ctx가 있습니다. 함수는 지정된 매개변수가 제공된 규칙이 재현 가능함을 나타내는 None을 반환하거나, 해당 규칙을 동일한 저장소를 생성하는 재현 가능한 규칙으로 전환하는 규칙의 매개변수 집합이 포함된 dict를 반환합니다. 예를 들어 원래 지정된 부동 분기 대신 특정 커밋 식별자를 반환하는 git 저장소를 추적하는 규칙이 있습니다.
입력 매개변수 repository_ctx를 사용하여 속성 값과 비밀폐 함수 (바이너리 찾기, 바이너리 실행, 저장소에서 파일 만들기 또는 인터넷에서 파일 다운로드)에 액세스할 수 있습니다. 자세한 내용은 API
문서를 참고하세요. 예:
def _impl(repository_ctx):
repository_ctx.symlink(repository_ctx.attr.path, "")
local_repository = repository_rule(
implementation=_impl,
...)
구현 함수는 언제 실행되나요?
저장소 규칙의 구현 함수는 다른 타겟 (다른 저장소에 있음)이 종속되거나 명령줄에 언급된 경우와 같이 Bazel에 해당 저장소의 타겟이 필요할 때 실행됩니다. 그러면 구현 함수가 파일 시스템에서 저장소를 만들 것으로 예상됩니다. 이를 저장소 '가져오기'라고 합니다.
일반 타겟과 달리 저장소는 저장소를 다르게 만드는 변경사항이 발생할 때 반드시 다시 가져오지 않습니다. 이는 Bazel이 변경사항을 감지할 수 없거나 모든 빌드에 너무 많은 오버헤드가 발생하기 때문입니다 (예: 네트워크에서 가져온 항목). 따라서 저장소는 다음 중 하나가 변경되는 경우에만 다시 가져옵니다.
- 저장소 규칙 호출에 전달된 속성
- 저장소 규칙의 구현을 구성하는 Starlark 코드
repository_ctx의getenv()메서드에 전달되거나environ속성으로 선언된repository_rule의 값 이러한 환경 변수의 값은 명령줄에서--repo_env플래그를 사용하여 하드와이어링할 수 있습니다.- 저장소 규칙의 구현 함수에서
`watch`
watched되는 모든 경로의 존재, 콘텐츠, 유형read(),execute(),extract()와 같이watch매개변수가 있는 특정 다른repository_ctx메서드도 경로를 감시하도록 할 수 있습니다.- 마찬가지로
repository_ctx.watch_tree및path.readdir은 다른 방식으로 경로 를 감시하도록 할 수 있습니다.
bazel fetch --force가 실행될 때
저장소가 다시 가져오는 시점을 제어하는 repository_rule의 두 가지 매개변수는 다음과 같습니다.
configure플래그가 설정된 경우 저장소는bazel fetch --force --configure에서 다시 가져옵니다 (configure가 아닌 저장소는 다시 가져오지 않음).local플래그가 설정된 경우 위의 경우 외에도 Bazel 서버가 다시 시작될 때 저장소가 다시 가져옵니다.
외부 저장소 강제 다시 가져오기
경우에 따라 정의나 종속 항목이 변경되지 않아도 외부 저장소가 오래될 수 있습니다. 예를 들어 소스를 가져오는 저장소는 서드 파티 저장소의 특정 분기를 따르고 해당 분기에서 새 커밋을 사용할 수 있습니다. 이 경우 bazel fetch --force --all을 호출하여 모든 외부 저장소를 무조건 다시 가져오도록 Bazel에 요청할 수 있습니다.
또한 일부 저장소 규칙은 로컬 머신을 검사하고 로컬 머신이 업그레이드된 경우 오래될 수 있습니다. 여기에서 Bazel에
외부 저장소만 다시 가져오도록 요청할 수 있습니다. repository_rule
정의에 configure 속성이 설정된 경우 bazel fetch --force
--configure를 사용하세요.
예
C++ 자동 구성 툴체인: 저장소 규칙을 사용하여 로컬 C++ 컴파일러, 환경, C++ 컴파일러가 지원하는 플래그를 찾아 Bazel용 C++ 구성 파일을 자동으로 만듭니다.
Go 저장소 는 여러
repository_rule을 사용하여 Go 규칙을 사용하는 데 필요한 종속 항목 목록을 정의합니다.rules_jvm_external 은 전이 종속 항목 트리의 모든 Maven 아티팩트에 대한 빌드 타겟을 생성하는
@maven이라는 외부 저장소를 기본적으로 만듭니다.