외부 종속 항목에 대한 고급 주제

Nightly · 9.1 · 9.0 · 8.7 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 8.1

WORKSPACE의 종속 항목 섀도잉

가능한 경우 프로젝트에 단일 버전 정책을 적용합니다. 이 정책은 컴파일하고 최종 바이너리에 포함되는 종속 항목에 필요합니다. 다른 경우에는 종속 항목을 섀도잉할 수 있습니다.

myproject/WORKSPACE

workspace(name = "myproject")

local_repository(
    name = "A",
    path = "../A",
)
local_repository(
    name = "B",
    path = "../B",
)

A/WORKSPACE

workspace(name = "A")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner",
    urls = ["https://github.com/testrunner/v1.zip"],
    sha256 = "...",
)

B/WORKSPACE 

workspace(name = "B")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner",
    urls = ["https://github.com/testrunner/v2.zip"],
    sha256 = "..."
)

종속 항목 A와 B는 모두 testrunner의 다른 버전에 종속됩니다. 충돌 없이 myproject에 둘 다 포함하려면 myproject/WORKSPACE에서 고유한 이름을 지정하세요.

workspace(name = "myproject")

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "testrunner-v1",
    urls = ["https://github.com/testrunner/v1.zip"],
    sha256 = "..."
)
http_archive(
    name = "testrunner-v2",
    urls = ["https://github.com/testrunner/v2.zip"],
    sha256 = "..."
)
local_repository(
    name = "A",
    path = "../A",
    repo_mapping = {"@testrunner" : "@testrunner-v1"}
)
local_repository(
    name = "B",
    path = "../B",
    repo_mapping = {"@testrunner" : "@testrunner-v2"}
)

이 메커니즘을 사용하여 다이아몬드를 조인할 수도 있습니다. 예를 들어 A와 B 에 동일한 종속 항목이 있지만 다른 이름으로 호출하는 경우 에서 이러한 종속 항목을 조인합니다.myproject/WORKSPACE

명령줄에서 저장소 재정의

명령줄에서 선언된 저장소를 로컬 저장소로 재정의하려면 다음 --override_repository 플래그를 사용합니다. 이 플래그를 사용하면 소스 코드를 변경하지 않고 외부 저장소의 콘텐츠를 변경할 수 있습니다.

예를 들어 @foo를 로컬 디렉터리 /path/to/local/foo로 재정의하려면 --override_repository=foo=/path/to/local/foo 플래그를 전달합니다.

사용 사례는 다음과 같습니다.

  • 디버깅 문제. 예를 들어 변경사항을 더 쉽게 적용할 수 있는 로컬 디렉터리로 http_archive 저장소를 재정의합니다.
  • 벤더링. 네트워크 호출을 할 수 없는 환경에 있는 경우 네트워크 기반 저장소 규칙을 재정의하여 대신 로컬 디렉터리를 가리킵니다.
명령어와 마찬가지로 모듈을 로컬 디렉터리로 재정의합니다.

프록시 사용

Bazel은 HTTPS_PROXY 및 HTTP_PROXY 환경 변수에서 프록시 주소를 가져와서 이를 사용하여 HTTP 및 HTTPS 파일을 다운로드합니다 (지정된 경우 ).

IPv6 지원

IPv6 전용 머신에서 Bazel은 변경사항 없이 종속 항목을 다운로드할 수 있습니다. 하지만 이중 스택 IPv4/IPv6 머신에서 Bazel은 Java와 동일한 규칙을 따르며 IPv4가 사용 설정된 경우 IPv4를 선호합니다. 경우에 따라(예: IPv4 네트워크에서 외부 주소를 확인하거나 연결할 수 없는 경우) Network unreachable 예외 및 빌드 실패가 발생할 수 있습니다. 이러한 경우 Bazel의 동작을 재정의하여 java.net.preferIPv6Addresses=true 시스템 속성을 사용하여 IPv6를 선호하도록 할 수 있습니다. 구체적인 내용은 다음과 같습니다.

오프라인 빌드

경우에 따라(예: 비행기를 타고 이동하는 경우) 오프라인으로 빌드를 실행하는 것이 좋습니다. 이러한 간단한 사용 사례의 경우 bazel fetch 또는 bazel sync를 사용하여 필요한 저장소를 프리페치합니다. 빌드 중에 추가 저장소를 가져오지 않도록 하려면 --nofetch 옵션을 사용합니다.

다른 항목이 필요한 모든 파일을 제공하는 진정한 오프라인 빌드의 경우 Bazel은 --distdir 옵션을 지원합니다. 이 플래그는 저장소 규칙에서 Bazel에 ctx.download 또는 ctx.download_and_extract로 파일을 가져오도록 요청할 때 Bazel이 먼저 해당 옵션으로 지정된 디렉터리를 찾도록 Bazel에 지시합니다. 필요한 파일의 해시 합계를 제공하면 Bazel은 첫 번째 URL의 기본 이름과 일치하는 파일을 찾고 해시가 일치하면 로컬 사본을 사용합니다.

Bazel 자체는 이 기법을 사용하여 배포 아티팩트에서 오프라인으로 부트스트랩합니다. 이렇게 하려면 필요한 모든 외부 종속 항목 을 내부 distdir_tar에 수집합니다.

Bazel은 네트워크를 호출하는지 여부를 알지 못하고 저장소 규칙에서 임의의 명령어를 실행할 수 있으므로 완전한 오프라인 빌드를 적용할 수 없습니다. 빌드가 오프라인에서 올바르게 작동하는지 테스트하려면 Bazel이 부트스트랩 테스트에서 수행하는 것처럼 네트워크를 수동으로 차단합니다.