BazelCon 2024 등록이 시작되었습니다

이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Bzlmod 이전 가이드

문제 신고 소스 보기 1박 · 7.2 · 7.1 · 7.0 · 6.5 · 6.4

하지만 이러한 기능의 단점은 WORKSPACE로 정의하면 Bzlmod가 기존의 WORKSPACE 시스템을 대체할 수 있습니다. 이 가이드는 프로젝트를 Bzlmod로 마이그레이션하고 외부를 가져오기 위해 WORKSPACE를 삭제하는 경우 종속 항목이 포함됩니다

WORKSPACE와 Bzlmod 비교

Bazel의 WORKSPACE와 Bzlmod는 유사한 기능을 제공하며 구문이 다릅니다. 이 섹션에서는 특정 WORKSPACE 기능에서 Bzlmod입니다.

Bazel 작업공간의 루트 정의

WORKSPACE 파일은 Bazel 프로젝트의 소스 루트를 표시하며, Bazel 버전 6.3 이상에서 MODULE.bazel로 대체됩니다. Bazel 버전 사용 6.3 이전에는 여전히 WORKSPACE 또는 WORKSPACE.bazel 파일이 다음과 같은 주석을 달아보세요.

작업공간

# This file marks the root of the Bazel workspace.
# See MODULE.bazel for external dependencies setup.

작업공간의 저장소 이름을 지정하세요.

작업공간

workspace 함수가 사용됩니다. 작업공간의 저장소 이름을 지정합니다. 이렇게 하면 @<workspace name>//foo:bar로 참조할 작업공간의 //foo:bar 지정하지 않으면 작업공간은 __main__입니다.
```
## WORKSPACE
workspace(name = "com_foo_bar")
```
Bzlmod

다음 명령어로 동일한 작업공간에서 타겟을 참조하는 것이 @<repo name>가 없는 //foo:bar 문법 하지만 이전 구문이 필요한 경우 가 포함되어 있는 경우, 저장소로 사용되는 module 함수 있습니다. 모듈 이름이 필요한 저장소 이름과 다르면 repo_name 속성을 사용할 수 있음 module 함수를 사용하여 저장소 이름
```
## MODULE.bazel
module(
    name = "bar",
    repo_name = "com_foo_bar",
)
```

외부 종속 항목을 Bazel 모듈로 가져오기

종속 항목이 Bazel 프로젝트인 경우 Bazel 모듈이 Bzlmod를 채택하는 경우

작업공간

WORKSPACE를 사용하면 일반적으로 http_archive 또는 git_repository 저장소 규칙을 사용하여 Bazel 프로젝트의 소스를 다운로드할 수 있습니다

## WORKSPACE
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "bazel_skylib",
    urls = ["https://github.com/bazelbuild/bazel-skylib/releases/download/1.4.2/bazel-skylib-1.4.2.tar.gz"],
    sha256 = "66ffd9315665bfaafc96b52278f57c7e2dd09f5ede279ea6d39b2be471e7e3aa",
)
load("@bazel_skylib//:workspace.bzl", "bazel_skylib_workspace")
bazel_skylib_workspace()

http_archive(
    name = "rules_java",
    urls = ["https://github.com/bazelbuild/rules_java/releases/download/6.1.1/rules_java-6.1.1.tar.gz"],
    sha256 = "76402a50ae6859d50bd7aed8c1b8ef09dae5c1035bb3ca7d276f7f3ce659818a",
)
load("@rules_java//java:repositories.bzl", "rules_java_dependencies", "rules_java_toolchains")
rules_java_dependencies()
rules_java_toolchains()

보시다시피 사용자가 전이적 로드에 필요한 종속 항목을 삭제합니다. bazel_skylib 및 rules_java는 platform의 정확한 버전인 platoform에 종속됩니다. 매크로의 순서에 따라 결정됩니다.

Bzlmod

Bzlmod를 사용하는 경우(Bazel Central에서 종속 항목을 사용할 수 있는 경우) 레지스트리 또는 커스텀 Bazel 레지스트리에 저장하기만 하면 bazel_dep 지시어.
```
## MODULE.bazel
bazel_dep(name = "bazel_skylib", version = "1.4.2")
bazel_dep(name = "rules_java", version = "6.1.1")
```
Bzlmod는 다음을 사용하여 Bazel 모듈 종속 항목을 전이적으로 확인합니다. MVS 알고리즘을 사용합니다. 따라서 platform의 필수 버전이 자동으로 선택됩니다.

Bazel 모듈로 종속 항목 재정의

루트 모듈로서 서로 다른 위치에서 Bazel 모듈 종속 항목을 재정의할 수 있습니다. 있습니다.

자세한 내용은 재정의 섹션을 참조하세요. 확인할 수 있습니다

사용 예는 예시 저장소

모듈 확장 프로그램으로 외부 종속 항목 가져오기

종속 항목이 Bazel 프로젝트가 아니거나 아직 Bazel에서 사용할 수 없는 경우 모듈 확장을 사용하여 도입할 수 있습니다.

작업공간

http_file를 사용하여 파일 다운로드 저장소 규칙을 따릅니다.

## WORKSPACE
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")

http_file(
    name = "data_file",
    url = "http://example.com/file",
    sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
)

Bzlmod

Bzlmod를 사용하면 정의를 .bzl 파일로 이동해야 합니다. 이 파일도 WORKSPACE와 Bzlmod 간에 정의를 공유할 수 있게 해줍니다. 이전 기간

## repositories.bzl
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
def my_data_dependency():
    http_file(
        name = "data_file",
        url = "http://example.com/file",
        sha256 = "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
    )

모듈 확장을 구현하여 종속 항목 매크로를 로드합니다. 사용자는 매크로의 동일한 .bzl 파일에 있어야 하지만 Bazel 이전 버전에서는 별도의 .bzl 파일에 정의하는 것이 좋습니다.

## extensions.bzl
load("//:repositories.bzl", "my_data_dependency")
def _non_module_dependencies_impl(_ctx):
    my_data_dependency()

non_module_dependencies = module_extension(
    implementation = _non_module_dependencies_impl,
)

저장소가 루트 프로젝트에 표시되도록 하려면 MODULE.bazel 파일의 모듈 확장 프로그램 및 저장소 사용

## MODULE.bazel
non_module_dependencies = use_extension("//:extensions.bzl", "non_module_dependencies")
use_repo(non_module_dependencies, "data_file")

모듈 확장 프로그램과의 외부 종속 항목 충돌 해결

프로젝트는 특정 기준에 따라 외부 저장소를 도입하는 매크로를 도움이 됩니다. 하지만 통화 중에 여러 명의 발신자가 있는 경우에는 충돌을 일으킬 수 있나요?

프로젝트 foo가 version를 있습니다.

## repositories.bzl in foo {:#repositories.bzl-foo}
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_file")
def data_deps(version = "1.0"):
    http_file(
        name = "data_file",
        url = "http://example.com/file-%s" % version,
        # Omitting the "sha256" attribute for simplicity
    )

작업공간

WORKSPACE를 사용하면 @foo에서 매크로를 로드하고 버전을 지정할 수 있습니다. 필요한 데이터 종속 항목을 가져올 수 있습니다 또 다른 종속 항목 @bar가 있다고 가정해 보겠습니다. 이 코드도 @foo에 종속되지만 다른 버전의 데이터가 필요합니다. 종속됩니다.
```
## WORKSPACE

# Introduce @foo and @bar.
...

load("@foo//:repositories.bzl", "data_deps")
data_deps(version = "2.0")

load("@bar//:repositories.bzl", "bar_deps")
bar_deps() # -> which calls data_deps(version = "3.0")
```
이 경우 최종 사용자는 WORKSPACE를 사용하여 필요한 버전을 가져옵니다. 데이터 레이크에서 가장 큰 WORKSPACE는 원하는 위치를 지정할 수 있는 적절한 방법을 종속 항목을 해결합니다

Bzlmod

Bzlmod를 사용하면 foo 프로젝트의 작성자가 모듈 확장을 사용하여 문제를 해결할 수 있습니다. 충돌합니다. 예를 들어 항상 모든 Bazel 모듈 간에 필요한 최대 데이터 종속 버전

## extensions.bzl in foo
load("//:repositories.bzl", "data_deps")

data = tag_class(attrs={"version": attr.string()})

def _data_deps_extension_impl(module_ctx):
    # Select the maximal required version in the dependency graph.
    version = "1.0"
    for mod in module_ctx.modules:
        for data in mod.tags.data:
            version = max(version, data.version)
    data_deps(version)

data_deps_extension = module_extension(
    implementation = _data_deps_extension_impl,
    tag_classes = {"data": data},
)

## MODULE.bazel in bar
bazel_dep(name = "foo", version = "1.0")

foo_data_deps = use_extension("@foo//:extensions.bzl", "data_deps_extension")
foo_data_deps.data(version = "3.0")
use_repo(foo_data_deps, "data_file")

## MODULE.bazel in root module
bazel_dep(name = "foo", version = "1.0")
bazel_dep(name = "bar", version = "1.0")

foo_data_deps = use_extension("@foo//:extensions.bzl", "data_deps_extension")
foo_data_deps.data(version = "2.0")
use_repo(foo_data_deps, "data_file")

이 경우 루트 모듈에는 데이터 버전 2.0이 필요하지만 종속 항목 bar에는 3.0이 필요합니다. foo의 모듈 확장 프로그램은 이 충돌을 해결하고 데이터에 대해 버전 3.0을(를) 자동으로 선택합니다. 종속됩니다.

서드 파티 패키지 관리자 통합

이전 섹션에 따르면 모듈 확장은 종속 항목 그래프의 정보를 확인하고 커스텀 로직을 수행하여 외부 저장소를 도입하기 위해 저장소 규칙을 호출하고, 이 방법은 이는 규칙 작성자가 모든 규칙을 통합하는 규칙 집합을 향상할 수 있는 좋은 방법을 패키지 관리자를 사용하도록 설정하는 것이 좋습니다

자세한 내용은 모듈 확장 프로그램 페이지를 참고하세요. 모듈 확장 프로그램 사용 방법을 알아보시기 바랍니다.

다음은 종속 항목을 가져오기 위해 이미 Bzlmod를 채택한 규칙 세트의 목록입니다. 패키지 관리자:

의사 패키지 관리자를 통합하는 최소한의 예는 예시 저장소

호스트 머신의 도구 모음 감지

Bazel 빌드 규칙이 호스트에서 사용할 수 있는 도구 모음을 감지해야 하는 경우 저장소 규칙을 사용하여 호스트 머신을 검사하고 도구 모음 정보를 외부 저장소로 내보냅니다.

작업공간

셸 도구 모음을 감지하기 위해 다음과 같은 저장소 규칙이 제공됩니다.

## local_config_sh.bzl
def _sh_config_rule_impl(repository_ctx):
    sh_path = get_sh_path_from_env("SH_BIN_PATH")

    if not sh_path:
        sh_path = detect_sh_from_path()

    if not sh_path:
        sh_path = "/shell/binary/not/found"

    repository_ctx.file("BUILD", """
load("@bazel_tools//tools/sh:sh_toolchain.bzl", "sh_toolchain")
sh_toolchain(
    name = "local_sh",
    path = "{sh_path}",
    visibility = ["//visibility:public"],
)
toolchain(
    name = "local_sh_toolchain",
    toolchain = ":local_sh",
    toolchain_type = "@bazel_tools//tools/sh:toolchain_type",
)
""".format(sh_path = sh_path))

sh_config_rule = repository_rule(
    environ = ["SH_BIN_PATH"],
    local = True,
    implementation = _sh_config_rule_impl,
)

WORKSPACE에서 저장소 규칙을 로드할 수 있습니다.

## WORKSPACE
load("//:local_config_sh.bzl", "sh_config_rule")
sh_config_rule(name = "local_config_sh")

Bzlmod

Bzlmod를 사용하면 모듈 확장 프로그램을 사용하여 동일한 저장소를 도입할 수 있습니다. 이는 지난번에 @data_file 저장소를 도입한 것과 비슷합니다. 섹션으로 이동합니다.

## local_config_sh_extension.bzl
load("//:local_config_sh.bzl", "sh_config_rule")

sh_config_extension = module_extension(
    implementation = lambda ctx: sh_config_rule(name = "local_config_sh"),
)

그런 다음 MODULE.bazel 파일의 확장 프로그램을 사용합니다.

## MODULE.bazel
sh_config_ext = use_extension("//:local_config_sh_extension.bzl", "sh_config_extension")
use_repo(sh_config_ext, "local_config_sh")

도구 모음 등록 및 실행 플랫폼

마지막 섹션에 이어 저장소 호스팅 도구 모음을 소개한 후 (예: local_config_sh)에 매핑하려면 있습니다.

작업공간

WORKSPACE를 사용하면 다음과 같은 방법으로 도구 모음을 등록할 수 있습니다.

도구 모음을 .bzl 파일에 등록하고 WORKSPACE 파일에 있습니다.

## local_config_sh.bzl
def sh_configure():
    sh_config_rule(name = "local_config_sh")
    native.register_toolchains("@local_config_sh//:local_sh_toolchain")

## WORKSPACE
load("//:local_config_sh.bzl", "sh_configure")
sh_configure()

또는 WORKSPACE 파일에 도구 모음을 직접 등록합니다.

## WORKSPACE
load("//:local_config_sh.bzl", "sh_config_rule")
sh_config_rule(name = "local_config_sh")
register_toolchains("@local_config_sh//:local_sh_toolchain")

Bzlmod

Bzlmod를 사용하면 register_toolchains 및 register_execution_platforms API는 MODULE.bazel 파일에서만 사용할 수 있습니다. 전화를 걸 수 없음 native.register_toolchains를 사용합니다.
```
## MODULE.bazel
sh_config_ext = use_extension("//:local_config_sh_extension.bzl", "sh_config_extension")
use_repo(sh_config_ext, "local_config_sh")
register_toolchains("@local_config_sh//:local_sh_toolchain")
```

로컬 저장소 도입

종속 항목을 로컬 저장소로 도입해야 할 때 종속 항목의 로컬 버전을 설정하거나 디렉터리를 외부 저장소로 내보냅니다.

작업공간

WORKSPACE를 사용하면 두 가지 네이티브 저장소 규칙인 local_repository 및 new_local_repository
```
## WORKSPACE
local_repository(
    name = "rules_java",
    path = "/Users/bazel_user/workspace/rules_java",
)
```
Bzlmod

Bzlmod를 사용하면 local_path_override(으)로 모듈을 로컬 경로로 재정의합니다.
```
## MODULE.bazel
bazel_dep(name = "rules_java")
local_path_override(
    module_name = "rules_java",
    path = "/Users/bazel_user/workspace/rules_java",
)
```
참고: local_path_override를 사용하면 로컬 디렉터리만 도입할 수 있습니다. 즉, MODULE.bazel 파일이 있어야 하고 종속 항목 중에 전이 종속 항목이 고려됨 있습니다. 또한 모든 모듈 재정의 지시문은 루트 모듈

모듈 확장이 있는 로컬 저장소를 도입할 수도 있습니다. 그러나 모듈 확장에서는 native.local_repository를 호출할 수 없습니다. 모든 네이티브 저장소 규칙을 철저하게 확립하기 위해 지속적인 노력이 이루어지고 있습니다( 진행 상황은 #18285) 그런 다음 모듈에서 상응하는 Starlark local_repository를 호출할 수 있습니다. 확장자가 포함됩니다. 또한 애플리케이션의 커스텀 버전을 차단 문제인 경우 저장소 규칙을 local_repository개 설정합니다.

바인드 대상

WORKSPACE의 bind 규칙은 지원 중단되었으며 Bzlmod에서 지원되지 않습니다. 이는 대상에 별칭을 제공하기 위해 특수 //external 패키지. 이를 사용하는 모든 사용자는 이전해야 합니다.

예를 들어, 영역 1에

## WORKSPACE
bind(
    name = "openssl",
    actual = "@my-ssl//src:openssl-lib",
)

이렇게 하면 다른 대상이 //external:openssl에 종속될 수 있습니다. 이전 가능한 항목: 다음과 같은 방법으로 벗어날 수 있습니다.

모든 //external:openssl 사용을 다음으로 바꿉니다. @my-ssl//src:openssl-lib입니다.
또는 alias 빌드 규칙 사용
- 패키지에 다음 타겟을 정의합니다 (예: //third_party).
```
## third_party/BUILD
alias(
    name = "openssl,
    actual = "@my-ssl//src:openssl-lib",
)
```
- 모든 //external:openssl 사용을 다음으로 바꿉니다. //third_party:openssl-lib입니다.

마이그레이션

이 섹션에서는 Bzlmod 이전에 관한 유용한 정보와 안내를 제공합니다. 프로세스입니다

WORKSPACE의 종속 항목 알아보기

마이그레이션의 첫 번째 단계는 어떤 종속 항목이 있는지 파악하는 것입니다. 그것은 API에 정확히 어떤 종속 항목이 적용되었는지 파악하기 어려울 수 있습니다 전이 종속 항목은 주로 *_deps로 로드되므로 WORKSPACE 파일 매크로가 포함되어 있습니다.

작업공간 확인 파일로 외부 종속 항목 검사

다행히도 깃발은 --experimental_repository_resolved_file 드림 도움이 될 수 있습니다 이 플래그는 기본적으로 '잠금 파일'을 생성합니다. 가져온 종속 항목을 업데이트해야 합니다 자세한 내용은 이 블로그에서 확인하실 수 있습니다. 게시물을 참고하세요.

다음 두 가지 방법으로 사용할 수 있습니다.

특정 대상을 빌드하는 데 필요한 외부 종속 항목의 정보 가져오기

bazel clean --expunge
bazel build --nobuild --experimental_repository_resolved_file=resolved.bzl //foo:bar

WORKSPACE 파일에 정의된 모든 외부 종속 항목의 정보 가져오기
```
bazel clean --expunge
bazel sync --experimental_repository_resolved_file=resolved.bzl
```
bazel sync 명령어를 사용하면 WORKSPACE 파일에는 다음이 포함됩니다.
- bind 사용
- register_toolchains 및 register_execution_platforms 사용
그러나 프로젝트가 크로스 플랫폼인 경우 특정 위치에서 bazel 동기화가 중단될 수 있습니다. 일부 저장소 규칙은 지원되는 환경에서만 올바르게 실행될 수 있기 때문에 지원합니다

명령어를 실행하면 resolved.bzl 파일에 종속 항목이 있습니다.

`bazel query`로 외부 종속 항목 검사

bazel query를 사용하여 저장소 규칙을 검사할 수도 있습니다.

bazel query --output=build //external:<repo name>

더 편리하고 빠르지만 bazel 쿼리는 외부 종속 항목 버전 주의해서 사용하세요. 외부 IP 주소 쿼리 및 검사 종속 항목을 새로운 하위 명령어를 사용하세요.

기본 제공 종속 항목

--experimental_repository_resolved_file에서 생성된 파일을 확인하면 WORKSPACE에 정의되지 않은 많은 종속 항목을 보게 될 것입니다. 이는 Bazel이 사용자의 WORKSPACE에 접두사와 접미사를 추가하기 때문입니다. 파일 콘텐츠를 사용하여 일부 기본 종속 항목을 삽입합니다. 이 종속 항목은 일반적으로 기본 규칙 (예: @bazel_tools, @platforms, @remote_java_tools) 다음으로 바꿉니다. Bzlmod, 이러한 종속 항목은 기본 제공 모듈을 통해 도입됨 bazel_tools - 다른 모든 종속 항목의 기본 종속 항목 Bazel 모듈과 함께 사용할 수 있습니다.

점진적 마이그레이션을 위한 하이브리드 모드

Bzlmod와 WORKSPACE가 함께 작동할 수 있으므로 종속 항목을 마이그레이션할 수 있습니다. Bzlmod로 변환합니다.

WORKSPACE.bzlmod

마이그레이션 중에 Bazel 사용자는 및 사용하지 않습니다. WORKSPACE.bzlmod 지원이 구현되어 더 매끄럽게 시작할 수 있습니다.

WORKSPACE.bzlmod에는 WORKSPACE와 정확히 동일한 구문이 있습니다. Bzlmod가 사용 설정되면 WORKSPACE.bzlmod 파일도 작업공간 루트에 있는 경우:

WORKSPACE.bzlmod이 적용되고 WORKSPACE의 콘텐츠는 무시됩니다.
접두사 또는 접미사 없음 WORKSPACE.bzlmod 파일에 추가됩니다

WORKSPACE.bzlmod 파일을 사용하면 다음과 같은 이유로 쉽게 이전할 수 있습니다.

Bzlmod가 사용 중지되면 원본 WORKSPACE 파일에 있습니다.
Bzlmod를 사용 설정하면 남은 종속 항목을 더 잘 추적할 수 있습니다. WORKSPACE.bzlmod를 사용하여 마이그레이션하세요.

를 통해 개인정보처리방침을 정의할 수 있습니다.

저장소 공개 상태

Bzlmod는 지정된 저장소에서 볼 수 있는 다른 저장소를 저장소 이름과 엄격한 deps를 참조하세요.

다음은 여러 유형의 저장소 가시성에 대한 요약입니다. WORKSPACE와도 같습니다.

	기본 저장소에서	Bazel 모듈 저장소	모듈 확장 프로그램 저장소에서	WORKSPACE 저장소에서
기본 저장소	표시	루트 모듈이 직접 종속 항목인 경우	루트 모듈이 모듈 확장 프로그램을 호스팅하는 모듈의 직접 종속 항목인 경우	표시
Bazel 모듈 저장소	직접 디핑	직접 디핑	모듈 확장 프로그램을 호스팅하는 모듈의 직접 deps	루트 모듈의 직접 deps
모듈 확장 저장소	직접 디핑	직접 디핑	모듈 확장을 호스팅하는 모듈의 직접 deps + 동일한 모듈 확장 프로그램에서 생성된 모든 저장소	루트 모듈의 직접 deps
WORKSPACE 저장소	모두 표시 중	표시 안 됨	표시 안 됨	모두 표시 중

마이그레이션 프로세스

일반적인 Bzlmod 마이그레이션 프로세스는 다음과 같습니다.

WORKSPACE에 어떤 종속 항목이 있는지 이해합니다.
프로젝트 루트에 빈 MODULE.bazel 파일을 추가합니다.
빈 WORKSPACE.bzlmod 파일을 추가하여 WORKSPACE 파일 콘텐츠를 재정의합니다.
Bzlmod를 사용 설정한 상태로 대상을 빌드하고 어떤 저장소가 사용 설정되어 있는지 확인 없습니다.
해결된 종속 항목에서 누락된 저장소의 정의 확인 파일에서 참조됩니다.
모듈을 통해 누락된 종속 항목을 Bazel 모듈로 도입 확장자를 사용하거나, 나중에 마이그레이션할 수 있도록 WORKSPACE.bzlmod에 남겨 두세요.
4로 돌아가서 모든 종속 항목을 사용할 수 있을 때까지 반복합니다.

마이그레이션 도구

이 스크립트에는 대화형 Bzlmod 이전 도우미 스크립트가 있습니다. 시작하는 데 도움이 될 것입니다

스크립트는 다음 작업을 실행합니다.

WORKSPACE 확인 파일을 생성하고 파싱합니다.
확인된 파일의 저장소 정보를 사람이 읽을 수 있는 방식으로 출력합니다.
bazel 빌드 명령어를 실행하고 인식된 오류 메시지를 감지하고 매우 중요합니다
BCR에서 이미 종속 항목을 사용할 수 있는지 확인합니다.
MODULE.bazel 파일에 종속 항목을 추가합니다.
모듈 확장 프로그램을 통해 종속 항목을 추가합니다.
WORKSPACE.bzlmod 파일에 종속 항목을 추가합니다.

사용하려면 최신 Bazel 출시 버전이 설치되어 있는지 확인하고 다음 명령어를 실행합니다.

git clone https://github.com/bazelbuild/bazel-central-registry.git
cd <your workspace root>
<BCR repo root>/tools/migrate_to_bzlmod.py -t <your build targets>

Bazel 모듈 게시

Bazel 프로젝트가 다른 프로젝트의 종속 항목인 경우 Bazel Central Registry 프로젝트에 있습니다.

BCR에서 프로젝트를 체크인하려면 다음의 소스 보관 URL이 필요합니다. 프로젝트입니다 소스 보관 파일을 만들 때 다음 사항에 유의하세요.

보관 파일이 특정 버전을 가리키는지 확인합니다.

Bzlmod는 반드시 버전이 지정된 소스 보관 파일만 허용하므로 종속 항목 해결 중에 버전 비교를 수행합니다.
보관 URL이 안정적인지 확인합니다.

Bazel은 해시 값으로 아카이브의 콘텐츠를 확인하므로 다운로드한 파일의 체크섬이 변경되지 않아야 합니다. URL이 출시 페이지에서 출시 자료실을 만들어 업로드하세요. GitHub는 디코더에서 생성된 소스 아카이브의 체크섬을 있습니다 간단히 말해 https://github.com/<org>/<repo>/releases/download/...가 안정적인 것으로 간주됨 반면 https://github.com/<org>/<repo>/archive/...는 그렇지 않습니다. GitHub 확인 체크섬 보관처리 서비스 중단 참조하세요
소스 트리가 원래 저장소의 레이아웃을 따르는지 확인합니다.

저장소가 매우 크고 배포판을 만들려고 하는 경우 불필요한 소스를 제거하여 크기를 줄인 보관 파일 제거된 소스 트리가 원본 소스 트리의 하위 집합임을 확인합니다. 이 최종 사용자가 모듈을 비출시 버전으로 쉽게 재정의할 수 있습니다. 버전: archive_override 및 git_override.
하위 디렉터리에 가장 일반적인 모듈을 테스트하는 테스트 모듈을 포함합니다. 제공합니다.

테스트 모듈은 자체 WORKSPACE 및 MODULE.bazel이 있는 Bazel 프로젝트입니다. .file은 소스 아카이브의 하위 디렉터리에 있으며 게시될 실제 모듈입니다. 예시 또는 몇 가지 예시를 포함해야 합니다. 통합 테스트를 실행할 수 있습니다. 확인 테스트 모듈을 참조하세요.

소스 보관 파일 URL이 준비되면 BCR 제공을 따릅니다. 가이드라인을 참고하여 GitHub를 사용하여 BCR에 모듈을 제출하세요. pull 요청

적극적으로 게시 대상 BCR GitHub App 모듈을 사용하여 BCR에 모듈을 제출하는 프로세스를 자동화할 수 있습니다.

권장사항

이 섹션에는 더 나은 성능을 위해 따라야 하는 몇 가지 권장사항이 나와 있습니다. 외부 종속 항목을 관리할 수 있습니다

불필요한 종속 항목을 가져오지 않도록 대상을 여러 패키지로 분할합니다.

#12835를 확인합니다. 여기서 dev는 빌드 시 불필요하게 테스트용 종속 항목을 가져와야 함 필요 없는 대상을 말합니다 실제로 Bzlmod에 특화된 것은 아니지만 이 권장사항을 따르면 개발 종속 항목을 더 쉽게 올바르게 지정할 수 있습니다.

개발 종속 항목 지정

다음과 같은 경우 dev_dependency 속성을 true로 설정할 수 있습니다. bazel_dep 및 use_extension 지시어를 사용하여 종속 프로젝트로 전파되지 않습니다 루트 모듈로 --ignore_dev_dependency 플래그를 사용하여 타겟이 개발 종속 항목 없이 빌드할 수 있습니다

커뮤니티 이전 진행 상황

Bazel Central 레지스트리에서 확인할 수 있습니다 아니면 언제든지 GitHub 토론에서 마이그레이션을 차단하는 종속 항목에 찬성 투표하거나 게시합니다.

문제 신고

알려진 Bzlmod에 관한 Bazel GitHub 문제 목록을 확인하세요. 있습니다 차단을 해제하는 데 도움이 될 수 있는 새로운 문제나 기능 요청을 언제든지 제출해 주세요. 도움이 될 것입니다

Bzlmod 이전 가이드

WORKSPACE와 Bzlmod 비교

Bazel 작업공간의 루트 정의

작업공간의 저장소 이름을 지정하세요.

외부 종속 항목을 Bazel 모듈로 가져오기

Bazel 모듈로 종속 항목 재정의

모듈 확장 프로그램으로 외부 종속 항목 가져오기

모듈 확장 프로그램과의 외부 종속 항목 충돌 해결

서드 파티 패키지 관리자 통합

호스트 머신의 도구 모음 감지

도구 모음 등록 및 실행 플랫폼

로컬 저장소 도입

바인드 대상

마이그레이션

WORKSPACE의 종속 항목 알아보기

작업공간 확인 파일로 외부 종속 항목 검사

bazel query로 외부 종속 항목 검사

기본 제공 종속 항목

점진적 마이그레이션을 위한 하이브리드 모드

WORKSPACE.bzlmod

저장소 공개 상태

마이그레이션 프로세스

마이그레이션 도구

Bazel 모듈 게시

권장사항

불필요한 종속 항목을 가져오지 않도록 대상을 여러 패키지로 분할합니다.

개발 종속 항목 지정

커뮤니티 이전 진행 상황

문제 신고

`bazel query`로 외부 종속 항목 검사