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