저장소 규칙

Nightly · 9.0 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

이 페이지에서는 저장소 규칙을 만드는 방법을 설명하고 자세한 내용을 위한 예를 제공합니다.

외부 저장소는 WORKSPACE 파일에서만 사용할 수 있는 규칙이며 Bazel의 로드 단계에서 기본 제공되지 않는 작업을 사용 설정합니다. 각 외부 저장소 규칙은 자체 자체 BUILD 파일과 아티팩트가 있는 작업공간을 만듭니다. 타사 라이브러리 (예: Maven 패키지 라이브러리)에 종속되는 데 사용할 수 있지만 Bazel이 실행되는 호스트에 고유한 BUILD 파일 을 생성하는 데에도 사용할 수 있습니다.

저장소 규칙 생성

.bzl 파일에서 repository_rule 함수를 사용하여 새 저장소 규칙을 만들고 전역 변수에 저장합니다.

커스텀 저장소 규칙은 기본 저장소 규칙과 마찬가지로 사용할 수 있습니다. 필수 name 속성이 있으며 빌드 파일에 있는 모든 타겟 은 @<name>//package:target으로 참조할 수 있습니다. 여기서 <name>은 name 속성의 값입니다.

규칙은 명시적으로 빌드하거나 빌드의 종속 항목인 경우 로드됩니다. 이 경우 Bazel은 implementation 함수를 실행합니다. 이 함수는 저장소, 콘텐츠, BUILD 파일을 만드는 방법을 설명합니다.

속성

속성은 attrs 규칙 인수에 dict로 전달되는 규칙 인수입니다. 속성과 그 유형은 저장소 규칙을 정의할 때 나열됩니다. url 및 sha256 속성을 문자열로 정의하는 예는 다음과 같습니다.

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에는 build 규칙과 마찬가지로 암시적으로 정의된 속성이 있습니다. 두 가지 암시적 속성은 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() 메서드에 전달되거나 environ 속성으로 선언된 repository_rule의 값 이러한 환경 변수의 값은 플래그를 사용하여 명령줄에서 하드와이어링할 수 있습니다. --repo_env
라벨 (예: //mypkg:label.txt, mypkg/label.txt 아님)로 참조되는 repository_ctx의 read(), execute() 및 유사한 메서드에 전달된 파일의 콘텐츠
bazel sync가 실행될 때

저장소가 다시 가져와지는 시점을 제어하는 repository_rule에는 두 가지 매개변수가 있습니다.

configure 플래그가 설정된 경우 bazel sync에 --configure 매개변수가 전달될 때만 저장소가 다시 가져와집니다 (속성이 설정되지 않은 경우 이 명령어로 다시 가져오기가 발생하지 않음).
local 플래그가 설정된 경우 위의 경우 외에도 Bazel 서버가 다시 시작되거나 저장소 선언에 영향을 미치는 파일 (예: WORKSPACE 파일 또는 로드하는 파일)이 변경될 때 저장소가 다시 가져와집니다. 변경사항으로 인해 저장소 또는 코드의 선언이 변경되었는지 여부와 관계없이 다시 가져와집니다.

이러한 경우 비로컬 저장소는 다시 가져와지지 않습니다. 이러한 저장소는 네트워크와 통신하거나 비용이 많이 드는 것으로 간주되기 때문입니다.

구현 함수 다시 시작

요청된 종속 항목이 누락 된 경우 저장소를 가져오는 동안 구현 함수를 다시 시작 할 수 있습니다. 이 경우 구현 함수의 실행이 중지되고 누락된 종속 항목이 해결되며 종속 항목이 해결된 후 함수가 다시 실행됩니다. 불필요한 다시 시작 (네트워크 액세스를 반복해야 할 수 있으므로 비용이 많이 듦)을 방지하기 위해 모든 라벨 인수를 기존 파일로 확인할 수 있는 경우 라벨 인수가 미리 가져와집니다. 함수 실행 중에만 구성된 문자열 또는 라벨에서 경로를 확인해도 다시 시작될 수 있습니다.

외부 저장소 강제 다시 가져오기

정의 또는 종속 항목이 변경되지 않아도 외부 저장소가 오래될 수 있습니다. 예를 들어 소스를 가져오는 저장소는 타사 저장소의 특정 분기를 따를 수 있으며 해당 분기에서 새 커밋을 사용할 수 있습니다. 이 경우 bazel에 모든 외부 저장소를 무조건 다시 가져오도록 요청할 수 있습니다. bazel sync

또한 일부 규칙은 로컬 머신을 검사하며 로컬 머신이 업그레이드된 경우 오래될 수 있습니다. 여기에서 bazel에 정의에 configure 속성이 설정된 외부 저장소만 다시 가져오도록 요청할 수 있습니다. bazel sync --configure를 사용하세요.repository_rule

예

C++ 자동 구성 툴체인: 저장소 규칙을 사용하여 로컬 C++ 컴파일러, 환경, C++ 컴파일러가 지원하는 플래그를 찾아 Bazel의 C++ 구성 파일을 자동으로 만듭니다.
Go 저장소 는 여러 repository_rule을 사용하여 종속 항목 목록 을 정의합니다.
rules_jvm_external은 전이 종속 항목 트리의 모든 Maven 아티팩트에 빌드 타겟을 생성하는 @maven이라는 외부 저장소를 기본적으로 만듭니다.

저장소 규칙 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.