rules_go
v0.50.1
메일링 리스트: bazel-go-discuss
Slack: #go on Bazel Slack, #bazel on Go Slack
규칙은 베타 개발 단계에 있습니다. 그들은 다음을 지원합니다:
현재 다음을 지원하지 않거나 제한적으로 지원합니다.
Go 규칙은 다음 호스트 플랫폼에서 테스트되고 지원됩니다.
사용자들은 다른 여러 플랫폼에서 성공했다고 보고했지만 규칙은 위에 나열된 플랫폼에서만 테스트되었습니다.
참고: 버전 v0.38.0부터 rule_go가 작동하려면 Bazel ≥ 5.4.0이 필요합니다.
master 브랜치는 최신 버전의 Bazel에서만 작동이 보장됩니다.
Bazel로 Go 코드를 빌드하려면 다음이 필요합니다.
PATH 에는 Bash, patch , cat 및 기타 Unix 도구가 있습니다.일반적으로 Go 툴체인을 설치할 필요는 없습니다. Bazel이 하나를 다운로드합니다.
Windows 관련 설정 지침은 Windows에서 rule_go 사용을 참조하세요. 몇 가지 추가 도구를 설치하고 구성해야 합니다.
Bazel의 새로운 외부 종속성 관리 시스템 Bzlmod를 사용하는 경우 전용 Go with Bzlmod 가이드를 참조하세요.
저장소 상단에 WORKSPACE 라는 파일을 생성하고 아래에 코드 조각을 추가하세요(또는 기존 WORKSPACE 에 추가하세요). 이는 Bazel에게 rule_go 및 해당 종속 항목을 가져오도록 지시합니다. Bazel은 최근 지원되는 Go 툴체인을 다운로드하고 사용하도록 등록합니다.
load ( "@bazel_tools//tools/build_defs/repo:http.bzl" , "http_archive" )
http_archive (
name = "io_bazel_rules_go" ,
integrity = "sha256-M6zErg9wUC20uJPJ/B3Xqb+ZjCPn/yxFF3QdQEmpdvg=" ,
urls = [
"https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/download/v0.48.0/rules_go-v0.48.0.zip" ,
"https://github.com/bazelbuild/rules_go/releases/download/v0.48.0/rules_go-v0.48.0.zip" ,
],
)
load ( "@io_bazel_rules_go//go:deps.bzl" , "go_register_toolchains" , "go_rules_dependencies" )
go_rules_dependencies ()
go_register_toolchains ( version = "1.23.1" ) http_archive 대신 git_repository를 사용하고 최근 커밋을 가리켜 master 에서 rule_go를 사용할 수 있습니다.
프로젝트의 루트 디렉터리에 BUILD.bazel 이라는 파일을 추가합니다. Go 코드가 있는 각 디렉터리에 빌드 파일이 필요하지만, 프로젝트에 Go 코드가 없더라도 루트 디렉터리에도 빌드 파일이 필요합니다. "Hello, world" 바이너리의 경우 파일은 다음과 같아야 합니다.
load ( "@io_bazel_rules_go//go:def.bzl" , "go_binary" )
go_binary (
name = "hello" ,
srcs = [ "hello.go" ],
) bazel build //:hello 사용하여 이 타겟을 빌드할 수 있습니다.
go build 로 프로젝트를 빌드할 수 있는 경우 Gazelle을 사용하여 빌드 파일을 자동으로 생성하고 업데이트할 수 있습니다.
bazel_gazelle 저장소와 해당 종속 항목을 WORKSPACE 에 추가하세요. 다음과 같아야 합니다.
load ( "@bazel_tools//tools/build_defs/repo:http.bzl" , "http_archive" ) http_archive ( name = "io_bazel_rules_go" , integrity = "sha256-M6zErg9wUC20uJPJ/B3Xqb+ZjCPn/yxFF3QdQEmpdvg=" , urls = [ "https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/download/v0.48.0/rules_go-v0.48.0.zip" , "https://github.com/bazelbuild/rules_go/releases/download/v0.48.0/rules_go-v0.48.0.zip" , ], ) http_archive ( name = "bazel_gazelle" , integrity = "sha256-12v3pg/YsFBEQJDfooN6Tq+YKeEWVhjuNdzspcvfWNU=" , urls = [ "https://mirror.bazel.build/github.com/bazelbuild/bazel-gazelle/releases/download/v0.37.0/bazel-gazelle-v0.37.0.tar.gz" , "https://github.com/bazelbuild/bazel-gazelle/releases/download/v0.37.0/bazel-gazelle-v0.37.0.tar.gz" , ], ) load ( "@io_bazel_rules_go//go:deps.bzl" , "go_register_toolchains" , "go_rules_dependencies" ) load ( "@bazel_gazelle//:deps.bzl" , "gazelle_dependencies" ) go_rules_dependencies () go_register_toolchains ( version = "1.23.1" ) gazelle_dependencies ()
프로젝트 루트 디렉터리의 BUILD.bazel 파일에 아래 코드를 추가합니다. prefix 뒤의 문자열을 프로젝트와 일치하는 가져오기 경로 접두사로 바꿉니다. go.mod 파일이 있는 경우 모듈 경로와 동일해야 합니다.
load ( "@bazel_gazelle//:def.bzl" , "gazelle" )
# gazelle:prefix github.com/example/project
gazelle ( name = "gazelle" ) 이는 아래 명령을 사용하여 실행할 수 있는 gazelle 바이너리 규칙을 선언합니다.
bazel run //:gazelle 그러면 프로젝트의 각 패키지에 대해 go_library, go_binary 및 go_test 대상이 포함된 BUILD.bazel 파일이 생성됩니다. 나중에 동일한 명령을 실행하여 기존 빌드 파일을 새로운 소스 파일, 종속성 및 옵션으로 업데이트할 수 있습니다.
프로젝트가 go build 규칙을 따르지 않거나 Gazelle을 사용하지 않으려는 경우 직접 빌드 파일을 작성할 수 있습니다.
Go 코드가 포함된 각 디렉터리에서 BUILD.bazel 이라는 파일을 만듭니다. 파일 상단에 사용하는 규칙에 대한 load 문을 추가합니다.
load ( "@io_bazel_rules_go//go:def.bzl" , "go_binary" , "go_library" , "go_test" ) 각 라이브러리에 대해 아래와 같은 go_library 규칙을 추가하세요. 소스 파일은 srcs 속성에 나열됩니다. 표준 라이브러리 외부에서 가져온 패키지는 해당 go_library 규칙을 참조하는 Bazel 레이블을 사용하여 deps 속성에 나열됩니다. 라이브러리의 가져오기 경로는 importpath 속성으로 지정되어야 합니다.
go_library (
name = "foo_library" ,
srcs = [
"a.go" ,
"b.go" ,
],
importpath = "github.com/example/project/foo" ,
deps = [
"//tools" ,
"@org_golang_x_utils//stuff" ,
],
visibility = [ "//visibility:public" ],
) 테스트를 위해 아래와 같은 go_test 규칙을 추가하세요. 테스트 중인 라이브러리는 embed 속성에 나열되어야 합니다.
go_test (
name = "foo_test" ,
srcs = [
"a_test.go" ,
"b_test.go" ,
],
embed = [ ":foo_lib" ],
deps = [
"//testtools" ,
"@org_golang_x_utils//morestuff" ,
],
)바이너리의 경우 아래와 같은 go_binary 규칙을 추가하세요.
go_binary (
name = "foo" ,
srcs = [ "main.go" ],
) 각 Go 저장소에 대해 아래와 같이 go_repository 규칙을 WORKSPACE 에 추가하세요. 이 규칙은 Gazelle 저장소에서 제공되므로 이를 로드해야 합니다. Gazelle update-repos는 go.mod 또는 Gopkg.lock 파일에서 자동으로 이러한 규칙을 생성하거나 업데이트할 수 있습니다.
load ( "@bazel_tools//tools/build_defs/repo:http.bzl" , "http_archive" )
# Download the Go rules.
http_archive (
name = "io_bazel_rules_go" ,
integrity = "sha256-M6zErg9wUC20uJPJ/B3Xqb+ZjCPn/yxFF3QdQEmpdvg=" ,
urls = [
"https://mirror.bazel.build/github.com/bazelbuild/rules_go/releases/download/v0.48.0/rules_go-v0.48.0.zip" ,
"https://github.com/bazelbuild/rules_go/releases/download/v0.48.0/rules_go-v0.48.0.zip" ,
],
)
# Download Gazelle.
http_archive (
name = "bazel_gazelle" ,
integrity = "sha256-12v3pg/YsFBEQJDfooN6Tq+YKeEWVhjuNdzspcvfWNU=" ,
urls = [
"https://mirror.bazel.build/github.com/bazelbuild/bazel-gazelle/releases/download/v0.37.0/bazel-gazelle-v0.37.0.tar.gz" ,
"https://github.com/bazelbuild/bazel-gazelle/releases/download/v0.37.0/bazel-gazelle-v0.37.0.tar.gz" ,
],
)
# Load macros and repository rules.
load ( "@io_bazel_rules_go//go:deps.bzl" , "go_register_toolchains" , "go_rules_dependencies" )
load ( "@bazel_gazelle//:deps.bzl" , "gazelle_dependencies" , "go_repository" )
# Declare Go direct dependencies.
go_repository (
name = "org_golang_x_net" ,
importpath = "golang.org/x/net" ,
sum = "h1:7EYJ93RZ9vYSZAIb2x3lnuvqO5zneoD6IvWjuhfxjTs=" ,
version = "v0.23.0" ,
)
# Declare indirect dependencies and register toolchains.
go_rules_dependencies ()
go_register_toolchains ( version = "1.23.1" )
gazelle_dependencies () 프로토콜 버퍼에서 코드를 생성하려면 com_google_protobuf 에 대한 종속성을 WORKSPACE 에 추가해야 합니다.
load ( "@bazel_tools//tools/build_defs/repo:http.bzl" , "http_archive" )
http_archive (
name = "com_google_protobuf" ,
sha256 = "535fbf566d372ccf3a097c374b26896fa044bf4232aef9cab37bd1cc1ba4e850" ,
strip_prefix = "protobuf-3.15.0" ,
urls = [
"https://mirror.bazel.build/github.com/protocolbuffers/protobuf/archive/v3.15.0.tar.gz" ,
"https://github.com/protocolbuffers/protobuf/archive/v3.15.0.tar.gz" ,
],
)
load ( "@com_google_protobuf//:protobuf_deps.bzl" , "protobuf_deps" )
protobuf_deps ()protoc을 빌드하려면 실행 플랫폼(Bazel이 작업을 실행하는 플랫폼)에 등록된 C/C++ 도구 체인이 필요합니다.
proto_library 규칙은 rules_proto 저장소에서 제공됩니다. Go proto 컴파일러 플러그인 protoc-gen-go 는 com_github_golang_protobuf 저장소에서 제공됩니다. 둘 다 go_rules_dependents에 의해 선언됩니다. 특별히 다른 버전을 사용하려는 경우가 아니면 명시적인 종속성을 선언할 필요가 없습니다. 다른 버전 사용에 대한 지침은 종속성 재정의를 참조하세요.
gRPC 종속성은 기본적으로 선언되지 않습니다(너무 많습니다). go_repository를 사용하여 WORKSPACE에서 선언할 수 있습니다. go.mod 에서 가져오려면 Gazelle update-repos를 사용하는 것이 좋습니다.
자세한 내용은 Proto 종속성, gRPC 종속성을 참조하세요. 충돌 방지도 참조하세요.
모든 종속성이 등록되면 proto_library 및 go_proto_library 규칙을 선언하여 .proto 파일에서 Go 코드를 생성하고 컴파일할 수 있습니다.
load ( "@rules_proto//proto:defs.bzl" , "proto_library" )
load ( "@io_bazel_rules_go//proto:def.bzl" , "go_proto_library" )
proto_library (
name = "foo_proto" ,
srcs = [ "foo.proto" ],
deps = [ "//bar:bar_proto" ],
visibility = [ "//visibility:public" ],
)
go_proto_library (
name = "foo_go_proto" ,
importpath = "github.com/example/protos/foo_proto" ,
protos = [ ":foo_proto" ],
visibility = [ "//visibility:public" ],
) go_proto_library 대상은 일반 go_library 처럼 가져오고 의존할 수 있습니다.
최신 버전의 rule_go는 APIv1( github.com/golang/protobuf )과 APIv2( google.golang.org/protobuf )를 모두 지원합니다. 기본적으로 두 인터페이스와의 호환성을 위해 github.com/golang/protobuf/cmd/protoc-gen-gen 사용하여 코드가 생성됩니다. 클라이언트 코드는 런타임 라이브러리 중 하나 또는 둘 다를 사용하여 가져올 수 있습니다.
가다
프로토콜 버퍼
종속성 및 테스트
예, 하지만 직접적으로는 아닙니다.
rule_go는 go_binary 및 기타 규칙으로 설명된 대상을 기반으로 Go 컴파일러와 링커를 직접 호출합니다. Bazel과 rule_go는 함께 go 명령과 동일한 역할을 수행하므로 Bazel 작업공간에서 go 명령을 사용할 필요가 없습니다.
즉, 일반적으로 go 명령에 필요한 규칙을 따르는 것이 좋습니다(예: 디렉터리당 하나의 패키지, 패키지 경로가 디렉터리 경로와 일치). Bazel과 호환되지 않는 도구는 계속 작동하며 프로젝트는 Bazel이 아닌 프로젝트에 의존할 수 있습니다.
Bazel에서 다루지 않는 작업(예: go.mod 에 새 종속성 추가)을 수행하기 위해 go 명령을 사용해야 하는 경우 다음 Bazel 호출을 사용하여 Bazel로 구성된 Go SDK의 go 바이너리를 실행할 수 있습니다.
bazel run @io_bazel_rules_go//go -- < args > Go 버전이 rule_go에서 사용되는 버전과 동일하다는 것을 보장하므로 go 직접 실행하는 것보다 이 방법을 선호합니다.
예, 하지만 직접적으로는 아닙니다. Bazel은 go.mod 파일을 무시하며 모든 패키지 종속성은 go_library 및 기타 규칙으로 설명된 대상의 deps 속성을 통해 표현되어야 합니다.
Gazelle에서 제공하는 작업공간 규칙인 go_repository를 사용하여 특정 버전의 Go 모듈을 외부 저장소로 다운로드할 수 있습니다. 그러면 Gazelle을 사용하여 빌드 파일도 생성됩니다.
Gazelle update-repos를 사용하여 go.mod 파일에서 go_repository 규칙을 가져올 수 있습니다.
이는 importpath 속성을 사용할 수 있기 전에 go build 로 빌드할 수 있는 라이브러리에서 가져오기 경로를 일관되게 유지하는 데 사용되었습니다.
올바르게 컴파일하고 링크하려면 rule_go가 각 라이브러리에 대한 Go 가져오기 경로(패키지를 가져올 수 있는 문자열)를 알아야 합니다. 이제 importpath 속성을 사용하여 명시적으로 설정됩니다. 해당 속성이 존재하기 전에는 특수 go_prefix 규칙의 문자열과 라이브러리의 패키지 및 레이블 이름을 연결하여 가져오기 경로가 유추되었습니다. 예를 들어, go_prefix 가 github.com/example/project 이고 //foo/bar:bar 라이브러리의 경우 rule_go는 가져오기 경로를 github.com/example/project/foo/bar/bar 로 추론합니다. 마지막 부분의 끊김은 go build 와 호환되지 않으므로 라벨 이름이 go_default_library 이면 가져오기 경로에 포함되지 않습니다. 따라서 //foo/bar:go_default_library 라이브러리의 경우 가져오기 경로는 github.com/example/project/foo/bar 입니다.
go_prefix 제거되고 importpath 속성이 필수가 되었기 때문에(#721 참조) go_default_library 이름은 더 이상 어떤 용도로도 사용되지 않습니다. 우리는 앞으로 이 기능의 사용을 중단하기로 결정할 수도 있습니다(#265 참조).
명령줄에서 --platforms 플래그를 설정하여 크로스 컴파일할 수 있습니다. 예를 들어:
$ bazel 빌드 --platforms=@io_bazel_rules_go//go/toolchain:linux_amd64 //cmd
기본적으로 크로스 컴파일 시 cgo는 비활성화됩니다. cgo와 크로스 컴파일하려면 대상 플랫폼에 _cgo 접미사를 추가하세요. 이 작업을 수행하려면 Bazel에 크로스 컴파일 C/C++ 도구 체인을 등록해야 합니다.
$ bazel 빌드 --platforms=@io_bazel_rules_go//go/toolchain:linux_amd64_cgo //cmd
빌드 태그나 파일 이름 접미사가 있는 플랫폼별 소스는 컴파일 타임에 자동으로 필터링됩니다. select 표현식을 사용하여 플랫폼별 종속성을 선택적으로 포함할 수 있습니다(Gazelle은 이 작업을 자동으로 수행함).
go_library (
name = "foo" ,
srcs = [
"foo_linux.go" ,
"foo_windows.go" ,
],
deps = select ({
"@io_bazel_rules_go//go/platform:linux_amd64" : [
"//bar_linux" ,
],
"@io_bazel_rules_go//go/platform:windows_amd64" : [
"//bar_windows" ,
],
"//conditions:default" : [],
}),
)대상 플랫폼에 대한 특정 go_binary 대상을 빌드하거나 특정 golang SDK 버전을 사용하려면 go_cross_binary 규칙을 사용하세요. 이는 단일 빌드에서 다양한 플랫폼에 대한 여러 바이너리를 생성하는 데 유용합니다.
대상 플랫폼에 대한 특정 go_test 대상을 빌드하려면 해당 규칙에 goos 및 goarch 속성을 설정하세요.
//command_line_option:platforms 의 Bazel 구성 전환을 통해 go_binary 또는 go_test 규칙에 동등하게 의존할 수 있습니다(rules_go 0.23.0 이전에는 이 접근 방식에 문제가 있었습니다).
Bazel은 샌드박스에서 테스트를 실행합니다. 즉, 테스트가 파일에 자동으로 액세스할 수는 없습니다. data 속성을 사용하여 테스트 파일을 포함해야 합니다. 예를 들어, testdata 디렉토리에 모든 것을 포함시키려면 다음을 수행하십시오.
go_test (
name = "foo_test" ,
srcs = [ "foo_test.go" ],
data = glob ([ "testdata/**" ]),
importpath = "github.com/example/project/foo" ,
) 기본적으로 테스트는 테스트를 정의한 빌드 파일의 디렉터리에서 실행됩니다. 이는 저장소 루트에서 실행되는 다른 언어가 따르는 Bazel 규칙이 아니라 Go 테스트 규칙을 따릅니다. 이는 상대 경로를 사용하여 테스트 파일에 액세스할 수 있음을 의미합니다. rundir 속성을 사용하여 테스트 디렉터리를 변경할 수 있습니다. go_test를 참조하세요.
Gazelle은 빌드 가능한 .go 파일이나 빌드 파일을 포함 하지 않는 한 testdata 디렉토리가 있는 경우 위와 같은 data 속성을 자동으로 추가합니다. 이 경우 testdata 일반 패키지로 처리됩니다.
Windows에서는 테스트 데이터 파일이 기호 링크에 의존하고 기본적으로 Windows에서는 권한이 없는 사용자가 기호 링크를 생성하는 것을 허용하지 않기 때문에 데이터 파일을 테스트에 직접 사용할 수 없습니다. github.com/bazelbuild/rules_go/go/tools/bazel 라이브러리를 사용하여 데이터 파일에 액세스할 수 있습니다.
go_binary 실행 파일을 작성하는 위치는 rule_go 버전 전체에서 안정적이지 않으므로 의존해서는 안 됩니다. 상위 디렉터리에는 이름에 일부 구성 데이터가 포함되어 있습니다. 이렇게 하면 동일한 바이너리가 다른 구성으로 빌드될 때 Bazel의 캐시가 손상되는 것을 방지할 수 있습니다. 바이너리 기본 이름은 플랫폼에 따라 다를 수도 있습니다. Windows에서는 .exe 확장자를 추가합니다.
go_test 규칙의 실행 파일에 의존하려면 data 속성에서 실행 파일을 참조한 다음(표시되도록) args 에서 위치를 확장합니다. 실제 위치는 명령줄의 테스트에 전달됩니다. 예를 들어:
go_binary (
name = "cmd" ,
srcs = [ "cmd.go" ],
)
go_test (
name = "cmd_test" ,
srcs = [ "cmd_test.go" ],
args = [ "$(location :cmd)" ],
data = [ ":cmd" ],
)바이너리에 액세스하는 테스트의 전체 예는 //tests/core/cross를 참조하세요.
또는 go_binary의 out 속성을 특정 파일 이름으로 설정할 수 있습니다. out 이 설정되면 구성을 변경할 때 바이너리가 캐시되지 않습니다.
go_binary (
name = "cmd" ,
srcs = [ "cmd.go" ],
out = "cmd" ,
)
go_test (
name = "cmd_test" ,
srcs = [ "cmd_test.go" ],
data = [ ":cmd" ],
)proto 문서에서 충돌 방지를 참조하세요.
이는 지원되지 않습니다. @io_bazel_rules_go//proto:go_grpc 컴파일러와 함께 go_proto_library를 사용하면 @org_golang_google_grpc//:go_default_library 에 암시적 종속성이 추가됩니다. //vendor/google.golang.org/grpc:go_default_library 또는 다른 곳에서 동일한 패키지의 다른 사본을 링크하는 경우 컴파일 또는 런타임 시 충돌이 발생할 수 있습니다.
proto 규칙 생성이 활성화된 Gazelle을 사용하는 경우 google.golang.org/grpc 가져오기는 충돌을 피하기 위해 자동으로 @org_golang_google_grpc//:go_default_library 로 확인됩니다. 이 경우 공급업체 gRPC를 무시해야 합니다.
공급업체 gRPC 패키지를 특별히 사용해야 하는 경우 go_proto_library 함께 사용하지 않는 것이 가장 좋습니다. 미리 생성된 .pb.go 파일을 체크인하고 go_library 규칙을 사용하여 빌드할 수 있습니다. Gazelle은 proto 규칙 생성이 비활성화되면 이러한 규칙을 생성합니다(루트 빌드 파일에 # gazelle:proto disable_global 추가).
go_rules_dependent에 선언된 저장소 재정의에 대한 지침은 종속성 재정의를 참조하세요.
참고자료:
Travis CI에서 Bazel 테스트를 실행하려면 before_install 스크립트에 Bazel을 설치해야 합니다. 위에 링크된 구성 파일을 참조하세요.
테스트 환경에서 Bazel이 엄청난 양의 메모리를 소비하는 것을 방지하려면 여러 플래그를 사용하여 Bazel을 실행하는 것이 좋습니다.
--host_jvm_args=-Xmx500m --host_jvm_args=-Xms500m : 최대 및 초기 JVM 힙 크기를 설정합니다. 동일하게 유지한다는 것은 JVM이 힙을 늘리는 데 시간을 소비하지 않는다는 것을 의미합니다. 힙 크기의 선택은 다소 임의적입니다. 다른 구성 파일에서는 최대 2500m의 제한을 권장합니다. 값이 높을수록 빌드 속도가 빨라지지만 OOM 종료 위험이 높아집니다.--bazelrc=.test-bazelrc : Travis CI 전용 Bazel 구성 파일을 사용합니다. 나머지 옵션은 대부분 여기에 넣을 수 있습니다.build --spawn_strategy=standalone --genrule_strategy=standalone : 빌드에 대한 샌드박싱을 비활성화합니다. mount 시스템 호출이 허용되지 않기 때문에 Travis 컨테이너 내부에서 샌드박싱이 실패할 수 있습니다.test --test_strategy=standalone : 테스트용 샌드박싱도 비활성화합니다.--local_resources=1536,1.5,0.5 : 사용 가능한 RAM(MB), 컴퓨팅에 사용 가능한 코어, I/O에 사용 가능한 코어에 대한 Bazel 제한을 설정합니다. 값이 높을수록 빌드 속도가 빨라지지만 경합이 높아지고 OOM 종료 위험이 커집니다.--noshow_progress : 더 깔끔한 로그에 대한 출력에서 진행 메시지를 표시하지 않습니다.--verbose_failures : 더 자세한 실패 메시지를 가져옵니다.--test_output=errors : Travis 로그에 테스트 stderr을 표시합니다. 일반적으로 테스트 출력은 Travis가 저장하거나 보고하지 않는 로그 파일로 작성됩니다. Travis의 다운로드는 상대적으로 느리므로(네트워크 경합이 심함) 빌드에서 네트워크 I/O 양을 최소화하는 것이 좋습니다. Bazel과 Go SDK를 다운로드하는 것이 그 중 큰 부분을 차지합니다. Go SDK 다운로드를 방지하려면 .travis.yml 파일에 사전 설치된 Go 버전이 있는 컨테이너를 요청한 다음 Travis 관련 WORKSPACE 파일에서 go_register_toolchains(go_version = "host") 호출할 수 있습니다.
Bazel의 캐시를 Travis 캐시에 넣고 싶은 유혹을 느낄 수도 있습니다. 이렇게 하면 빌드 속도가 크게 향상될 수 있지만 Travis는 캐시를 Amazon에 저장하므로 전송하는 데 매우 오랜 시간이 걸립니다. 실제로는 클린 빌드가 더 빠른 것 같습니다.
rule_go는 Go SDK의 공식 릴리스만 지원합니다. 그러나 "1.16beta1" 과 같은 version go_register_toolchains에 전달하여 베타 및 RC 버전을 계속 테스트할 수 있습니다. go_download_sdk도 참조하세요.
load ( "@io_bazel_rules_go//go:deps.bzl" , "go_register_toolchains" , "go_rules_dependencies" )
go_rules_dependencies ()
go_register_toolchains ( version = "1.17beta1" )
