저장소 규칙

<ph type="x-smartling-placeholder"></ph> 문제 신고 <ph type="x-smartling-placeholder"></ph> 소스 보기 1박 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5 를 참조하세요.

이 페이지에서는 저장소 규칙을 정의하는 방법을 설명하고 확인하세요.

외부 저장소는 디렉터리 트리입니다. Bazel 빌드에서 사용할 수 있는 소스 파일을 포함하는 해당 repo 규칙을 실행합니다. 저장소는 각 저장소는 빌드 대상은 빌드 규칙을 호출하여 정의합니다. 이러한 포드는 타사 라이브러리 (예: Maven 패키지 라이브러리)를 사용할 수 있을 뿐 아니라 Bazel이 실행 중인 호스트와 관련된 BUILD 파일

저장소 규칙 정의

.bzl 파일에서 repository_rule 함수를 사용하여 만들고 전역 변수에 저장합니다. 저장소 규칙을 정의한 후에는 저장소를 정의하는 함수로 호출할 수 있습니다. 이 호출은 일반적으로 모듈 확장 프로그램 구현 내부에서 실행 함수를 사용하세요.

저장소 규칙 정의의 두 가지 주요 구성요소는 속성 스키마와 구현 함수입니다. 속성 스키마는 속성을 설정하고 구현 함수는 저장소를 가져와야 할 때 실행됩니다

속성

속성은 저장소 규칙 호출에 전달되는 인수입니다. 스키마 저장소 규칙에서 허용하는 속성은 다음 경우에 attrs 인수를 사용하여 지정됩니다. 저장소 규칙은 repository_rule 호출로 정의됩니다. Kubernetes 문자열인 urlsha256 속성:

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에 예를 들어 다른 대상 (다른 repo)는 여기에 종속되거나 명령줄에서 언급되는지 여부입니다. 이 구현 함수는 파일에 저장소를 만들고 있습니다. 이를 '가져오기'라고 합니다. 확인할 수 있습니다

일반 대상과 달리 저장소는 저장소가 달라질 수 있는 변경사항 이것은 Bazel이 변경사항을 감지할 수 없거나 모든 빌드에 너무 많은 오버헤드를 초래 (예: 삭제됩니다. 따라서 다른 리전 중 하나가 다음과 같은 사항이 변경됩니다.

  • 저장소 규칙 호출에 전달된 속성입니다.
  • 저장소 규칙의 구현을 구성하는 Starlark 코드
  • repository_ctxgetenv() 메서드 또는 environ 속성으로 선언하여 repository_rule 값 이러한 환경 변수는 명령줄에서 --repo_env 플래그
  • read(), execute() 등에 전달되는 파일의 콘텐츠 repository_ctx의 메서드 (예: //mypkg:label.txt(mypkg/label.txt 아님)
  • bazel fetch --force 실행 시

repository_rule에는 저장소가 보관되는 시점을 제어하는 두 개의 매개변수가 있습니다. 다시 가져옵니다.

  • configure 플래그를 설정하면 다음 위치에서만 저장소를 다시 가져옵니다. --configure 매개변수가 전달된 경우 bazel fetch( 속성을 설정하지 않은 경우 이 명령어로 인해 다시 가져오기가 발생하지 않음)
  • local 플래그가 설정되면 위의 사례 외에도 저장소가 다음과 같이 됩니다. Bazel 서버가 다시 시작되면 다시 가져옵니다.

구현 함수 다시 시작

저장소가 생성되는 동안 구현 함수를 다시 시작할 수 있습니다. 요청한 종속 항목이 누락된 경우 가져올 수 있습니다. 이 경우 구현 함수가 중지되고 누락된 종속 항목이 해결되며 종속 항목이 해결된 후에 함수가 다시 실행됩니다. 받는사람 불필요한 재시작을 피해야 하며, 이는 네트워크 액세스가 차단되고 를 반복해야 함), 라벨 인수는 미리 가져온다. 라벨 인수는 기존 파일로 변환될 수 있습니다. 참고: 실행 중에만 생성된 문자열 또는 라벨의 경로 여전히 재시작될 수 있습니다

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

때로 외부 저장소는 종속 항목이 포함됩니다 예를 들어 저장소 가져오기 소스는 서드 파티 저장소의 특정 브랜치를 따르면 새 커밋이 해당 브랜치에서 사용할 수 있습니다 이 경우 Bazel에 모든 bazel fetch --force --all를 호출하여 무조건 외부 저장소에 저장합니다.

또한 일부 저장소 규칙은 로컬 머신을 검사하며 더 이상 유효하지 않을 수 있습니다 여기서 Bazel에게 해당 외부 저장소만 다시 가져옵니다. repository_rule 드림 정의에 configure 속성이 설정되어 있으므로 bazel fetch --all --configure입니다.

  • C++ 자동 구성 도구 모음: 저장소 규칙을 사용하여 자동으로 Bazel용 C++ 구성 파일은 로컬 C++ 컴파일러인 환경 및 C++ 컴파일러에서 지원하는 플래그로 구성됩니다.

  • Go 저장소 여러 repository_rule를 사용하여 종속 항목 목록을 정의합니다. Google Cloud Storage 버킷이 있습니다

  • rules_jvm_external이 기본적으로 빌드 타겟을 생성하는 @maven라는 외부 저장소 모든 Maven 아티팩트에 관해 API를 제공합니다.