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/WORKSPACE
에 고유한 이름을 지정하여 충돌 없이 myproject
에 둘 다 포함합니다.
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 네트워크가 외부 주소를 결정하거나 연결할 수 없는 등의 일부 상황에서는 Network
unreachable
예외 및 빌드 실패가 발생할 수 있습니다. 이러한 경우 java.net.preferIPv6Addresses=true
시스템 속성을 사용하여 IPv6을 우선 사용하도록 Bazel의 동작을 재정의할 수 있습니다.
특히 다음에 주의해야 합니다.
--host_jvm_args=-Djava.net.preferIPv6Addresses=true
시작 옵션을 사용합니다. 예를 들어.bazelrc
파일에 다음 줄을 추가합니다.startup --host_jvm_args=-Djava.net.preferIPv6Addresses=true
인터넷에 연결해야 하는 자바 빌드 타겟을 실행할 때 (예: 통합 테스트)
--jvmopt=-Djava.net.preferIPv6Addresses=true
도구 플래그를 사용합니다. 예를 들어.bazelrc
파일에 다음을 포함합니다.build --jvmopt=-Djava.net.preferIPv6Addresses
종속 항목 버전 확인에
rules_jvm_external
를 사용하는 경우COURSIER_OPTS
환경 변수에-Djava.net.preferIPv6Addresses=true
를 추가하여 Coursier용 JVM 옵션을 제공합니다.
오프라인 빌드
예를 들어 비행기로 이동할 때와 같이 빌드를 오프라인으로 실행해야 할 수 있습니다. 이러한 간단한 사용 사례에서는 bazel fetch
또는 bazel sync
를 사용하여 필요한 저장소를 미리 가져옵니다. 빌드 중에 추가 저장소 가져오기를 사용 중지하려면 --nofetch
옵션을 사용하세요.
다른 항목이 필요한 모든 파일을 제공하는 실제 오프라인 빌드의 경우 Bazel은 --distdir
옵션을 지원합니다. 이 플래그는 저장소 규칙이 Bazel에 ctx.download
또는 ctx.download_and_extract
를 사용하여 파일을 가져오도록 요청할 때 이 옵션으로 지정된 디렉터리를 먼저 살펴보도록 Bazel에 지시합니다. 필요한 파일의 해시 합계를 제공하여 Bazel은 첫 번째 URL의 기본 이름과 일치하는 파일을 찾고 해시가 일치하면 로컬 사본을 사용합니다.
Bazel 자체는 이 기법을 사용하여 배포 아티팩트에서 오프라인으로 부트스트랩합니다.
이를 위해 내부 distdir_tar
에서 필요한 모든 외부 종속 항목을 수집합니다.
Bazel은 네트워크 호출 여부를 알지 못한 채 저장소 규칙에서 임의의 명령어를 실행하도록 허용하므로 완전한 오프라인 빌드를 적용할 수 없습니다. 빌드가 오프라인에서 올바르게 작동하는지 테스트하려면 Bazel이 부트스트랩 테스트에서 하는 것처럼 네트워크를 수동으로 차단합니다.