Rules_go
v0.50.1
Mailingliste: bazel-go-discuss
Slack: #go auf Bazel Slack, #bazel auf Go Slack
Die Regeln befinden sich im Beta-Stadium der Entwicklung. Sie unterstützen:
Derzeit wird Folgendes nicht oder nur eingeschränkt unterstützt:
Die Go-Regeln werden auf den folgenden Hostplattformen getestet und unterstützt:
Benutzer haben auf mehreren anderen Plattformen über Erfolge berichtet, die Regeln werden jedoch nur auf den oben aufgeführten Plattformen getestet.
Hinweis: Seit Version v0.38.0 erfordert Rules_go Bazel ≥ 5.4.0, um zu funktionieren.
Es wird garantiert, dass der master -Zweig nur mit der neuesten Version von Bazel funktioniert.
Um Go-Code mit Bazel zu erstellen, benötigen Sie:
patch , cat und eine Handvoll anderer Unix-Tools in PATH .Normalerweise muss keine Go-Toolchain installiert sein. Bazel wird eines herunterladen.
Windows-spezifische Setup-Anweisungen finden Sie unter Rules_go unter Windows verwenden. Es müssen mehrere zusätzliche Tools installiert und konfiguriert werden.
Wenn Sie Bazels neues externes Abhängigkeitsmanagementsystem Bzlmod verwenden, lesen Sie stattdessen den speziellen Go with Bzlmod-Leitfaden.
Erstellen Sie oben in Ihrem Repository eine Datei mit dem Namen WORKSPACE und fügen Sie das Snippet unten hinzu (oder fügen Sie es zu Ihrem vorhandenen WORKSPACE hinzu). Dadurch wird Bazel angewiesen, Rules_go und seine Abhängigkeiten abzurufen. Bazel lädt eine aktuelle unterstützte Go-Toolchain herunter und registriert sie zur Verwendung.
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" ) Sie können Rules_go beim master verwenden, indem Sie git_repository anstelle von http_archive verwenden und auf ein aktuelles Commit verweisen.
Fügen Sie eine Datei mit dem Namen BUILD.bazel im Stammverzeichnis Ihres Projekts hinzu. Sie benötigen in jedem Verzeichnis eine Build-Datei mit Go-Code, aber auch eine im Stammverzeichnis, selbst wenn Ihr Projekt dort keinen Go-Code hat. Für eine „Hello, world“-Binärdatei sollte die Datei wie folgt aussehen:
load ( "@io_bazel_rules_go//go:def.bzl" , "go_binary" )
go_binary (
name = "hello" ,
srcs = [ "hello.go" ],
) Sie können dieses Ziel mit bazel build //:hello erstellen.
Wenn Ihr Projekt mit go build erstellt werden kann, können Sie Ihre Build-Dateien automatisch mit Gazelle generieren und aktualisieren.
Fügen Sie das bazel_gazelle -Repository und seine Abhängigkeiten zu Ihrem WORKSPACE hinzu. Es sollte so aussehen:
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 ()
Fügen Sie den folgenden Code zur Datei BUILD.bazel im Stammverzeichnis Ihres Projekts hinzu. Ersetzen Sie die Zeichenfolge nach prefix durch ein Importpfad-Präfix, das Ihrem Projekt entspricht. Es sollte mit Ihrem Modulpfad identisch sein, wenn Sie eine go.mod Datei haben.
load ( "@bazel_gazelle//:def.bzl" , "gazelle" )
# gazelle:prefix github.com/example/project
gazelle ( name = "gazelle" ) Dadurch wird eine gazelle Binärregel deklariert, die Sie mit dem folgenden Befehl ausführen können:
bazel run //:gazelle Dadurch wird eine BUILD.bazel Datei mit den Zielen go_library, go_binary und go_test für jedes Paket in Ihrem Projekt generiert. Sie können denselben Befehl in Zukunft ausführen, um vorhandene Build-Dateien mit neuen Quelldateien, Abhängigkeiten und Optionen zu aktualisieren.
Wenn Ihr Projekt nicht go build -Konventionen entspricht oder Sie Gazelle lieber nicht verwenden möchten, können Sie Build-Dateien von Hand schreiben.
Erstellen Sie in jedem Verzeichnis, das Go-Code enthält, eine Datei mit dem Namen BUILD.bazel Fügen Sie oben in der Datei eine load für die von Ihnen verwendeten Regeln hinzu.
load ( "@io_bazel_rules_go//go:def.bzl" , "go_binary" , "go_library" , "go_test" ) Fügen Sie für jede Bibliothek eine go_library-Regel wie die folgende hinzu. Quelldateien werden im srcs Attribut aufgeführt. Importierte Pakete außerhalb der Standardbibliothek werden im deps Attribut unter Verwendung von Bazel-Labels aufgelistet, die auf entsprechende go_library-Regeln verweisen. Der Importpfad der Bibliothek muss mit dem Attribut importpath angegeben werden.
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" ],
) Fügen Sie für Tests eine go_test-Regel wie die folgende hinzu. Die getestete Bibliothek sollte in einem embed aufgeführt sein.
go_test (
name = "foo_test" ,
srcs = [
"a_test.go" ,
"b_test.go" ,
],
embed = [ ":foo_lib" ],
deps = [
"//testtools" ,
"@org_golang_x_utils//morestuff" ,
],
)Fügen Sie für Binärdateien eine go_binary-Regel wie die folgende hinzu.
go_binary (
name = "foo" ,
srcs = [ "main.go" ],
) Fügen Sie für jedes Go-Repository eine go_repository-Regel wie die folgende zu WORKSPACE hinzu. Diese Regel stammt aus dem Gazelle-Repository und muss daher geladen werden. Gazelle Update-Repos können diese Regeln automatisch aus einer go.mod- oder Gopkg.lock-Datei generieren oder aktualisieren.
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 () Um Code aus Protokollpuffern zu generieren, müssen Sie Ihrem WORKSPACE eine Abhängigkeit von com_google_protobuf hinzufügen.
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 ()Sie benötigen eine C/C++-Toolchain, die für die Ausführungsplattform (die Plattform, auf der Bazel Aktionen ausführt) registriert ist, um ein Protokoll zu erstellen.
Die Regel „proto_library“ wird vom Repository rules_proto bereitgestellt. protoc-gen-go , das Go-Proto-Compiler-Plugin, wird vom com_github_golang_protobuf -Repository bereitgestellt. Beide werden durch go_rules_dependencies deklariert. Sie müssen keine explizite Abhängigkeit deklarieren, es sei denn, Sie möchten ausdrücklich eine andere Version verwenden. Anweisungen zur Verwendung einer anderen Version finden Sie unter Abhängigkeiten überschreiben.
gRPC-Abhängigkeiten werden standardmäßig nicht deklariert (es gibt zu viele). Sie können sie in WORKSPACE mit go_repository deklarieren. Möglicherweise möchten Sie Gazelle Update-Repos verwenden, um sie aus go.mod zu importieren.
Weitere Informationen finden Sie unter Proto-Abhängigkeiten, gRPC-Abhängigkeiten. Siehe auch Konflikte vermeiden.
Sobald alle Abhängigkeiten registriert wurden, können Sie die Regeln proto_library und go_proto_library deklarieren, um Go-Code aus .proto-Dateien zu generieren und zu kompilieren.
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" ],
) Ein go_proto_library Ziel kann wie eine normale go_library importiert werden und von ihm abhängig sein.
Beachten Sie, dass aktuelle Versionen von Rules_go sowohl APIv1 ( github.com/golang/protobuf ) als auch APIv2 ( google.golang.org/protobuf ) unterstützen. Standardmäßig wird Code mit github.com/golang/protobuf/cmd/protoc-gen-gen generiert, um die Kompatibilität mit beiden Schnittstellen zu gewährleisten. Der Client-Code kann beim Import eine der beiden Laufzeitbibliotheken oder beides verwenden.
Gehen
Protokollpuffer
Abhängigkeiten und Tests
Ja, aber nicht direkt.
Rules_go ruft den Go-Compiler und -Linker direkt auf, basierend auf den mit go_binary und anderen Regeln beschriebenen Zielen. Bazel und Rules_go erfüllen zusammen dieselbe Rolle wie der Befehl go , daher ist es nicht erforderlich, den Befehl go “ in einem Bazel-Arbeitsbereich zu verwenden.
Trotzdem ist es normalerweise immer noch eine gute Idee, die für den Befehl go erforderlichen Konventionen zu befolgen (z. B. ein Paket pro Verzeichnis, Paketpfade stimmen mit Verzeichnispfaden überein). Tools, die nicht mit Bazel kompatibel sind, funktionieren weiterhin, und Projekte, die nicht von Bazel stammen, können sich auf Ihr Projekt verlassen.
Wenn Sie den Befehl go verwenden müssen, um Aufgaben auszuführen, die Bazel nicht abdeckt (z. B. das Hinzufügen einer neuen Abhängigkeit zu go.mod ), können Sie den folgenden Bazel-Aufruf verwenden, um die go Binärdatei des von Bazel konfigurierten Go SDK auszuführen:
bazel run @io_bazel_rules_go//go -- < args > Dies ist der direkten Ausführung go vorzuziehen, da dadurch sichergestellt wird, dass die Version von Go mit der von Rules_go verwendeten Version identisch ist.
Ja, aber nicht direkt. Bazel ignoriert go.mod Dateien und alle Paketabhängigkeiten müssen durch deps Attribute in Zielen ausgedrückt werden, die mit go_library und anderen Regeln beschrieben werden.
Sie können ein Go-Modul in einer bestimmten Version als externes Repository herunterladen, indem Sie go_repository verwenden, eine von Gazelle bereitgestellte Arbeitsbereichsregel. Dadurch werden auch Build-Dateien mit Gazelle generiert.
Sie können go_repository-Regeln mit Gazelle Update-Repos aus einer go.mod -Datei importieren.
Dies wurde verwendet, um Importpfade in Bibliotheken konsistent zu halten, die mit go build erstellt werden können, bevor das importpath Attribut verfügbar war.
Um korrekt zu kompilieren und zu verknüpfen, muss Rules_go den Go-Importpfad (die Zeichenfolge, mit der ein Paket importiert werden kann) für jede Bibliothek kennen. Dies wird nun explizit mit dem Attribut importpath festgelegt. Bevor dieses Attribut existierte, wurde der Importpfad durch Verkettung einer Zeichenfolge aus einer speziellen go_prefix -Regel und dem Paket- und Labelnamen der Bibliothek abgeleitet. Wenn go_prefix beispielsweise github.com/example/project wäre, würde Rules_go für eine Bibliothek //foo/bar:bar den Importpfad als github.com/example/project/foo/bar/bar ableiten. Das Stottern am Ende ist nicht mit go build kompatibel. Wenn der Labelname also go_default_library wäre, würde er im Importpfad nicht enthalten sein. Für die Bibliothek //foo/bar:go_default_library wäre der Importpfad also github.com/example/project/foo/bar .
Da go_prefix entfernt wurde und das Attribut importpath obligatorisch wurde (siehe #721), erfüllt der Name go_default_library keinen Zweck mehr. Möglicherweise beschließen wir, es in Zukunft nicht mehr zu verwenden (siehe Nr. 265).
Sie können eine Cross-Kompilierung durchführen, indem Sie das Flag --platforms in der Befehlszeile setzen. Zum Beispiel:
$ bazel build --platforms=@io_bazel_rules_go//go/toolchain:linux_amd64 //cmd
Standardmäßig ist cgo beim Cross-Compilieren deaktiviert. Um eine Cross-Kompilierung mit cgo durchzuführen, fügen Sie der Zielplattform das Suffix _cgo hinzu. Damit dies funktioniert, müssen Sie eine Cross-Compiling-C/C++-Toolchain bei Bazel registrieren.
$ bazel build --platforms=@io_bazel_rules_go//go/toolchain:linux_amd64_cgo //cmd
Plattformspezifische Quellen mit Build-Tags oder Dateinamensuffixen werden beim Kompilieren automatisch gefiltert. Sie können plattformspezifische Abhängigkeiten selektiv mit select Ausdrücken einbeziehen (Gazelle erledigt dies automatisch).
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" : [],
}),
)Um ein bestimmtes go_binary-Ziel für eine Zielplattform zu erstellen oder eine bestimmte Golang-SDK-Version zu verwenden, verwenden Sie die Regel go_cross_binary. Dies ist nützlich, um in einem einzigen Build mehrere Binärdateien für verschiedene Plattformen zu erstellen.
Um ein bestimmtes go_test-Ziel für eine Zielplattform zu erstellen, legen Sie die Attribute goos und goarch für diese Regel fest.
Sie können sich durch einen Bazel-Konfigurationsübergang auf //command_line_option:platforms gleichermaßen auf eine go_binary- oder go_test-Regel verlassen (vor Rules_go 0.23.0 gab es Probleme mit diesem Ansatz).
Bazel führt Tests in einer Sandbox aus, was bedeutet, dass Tests nicht automatisch Zugriff auf Dateien haben. Sie müssen Testdateien mithilfe des data einschließen. Wenn Sie beispielsweise alles in das testdata aufnehmen möchten:
go_test (
name = "foo_test" ,
srcs = [ "foo_test.go" ],
data = glob ([ "testdata/**" ]),
importpath = "github.com/example/project/foo" ,
) Standardmäßig werden Tests im Verzeichnis der Build-Datei ausgeführt, die sie definiert hat. Beachten Sie, dass dies der Go-Testkonvention folgt, nicht der Bazel-Konvention anderer Sprachen, die im Repository-Stammverzeichnis ausgeführt werden. Das bedeutet, dass Sie über relative Pfade auf Testdateien zugreifen können. Sie können das Testverzeichnis mithilfe des rundir Attributs ändern. Siehe go_test.
Gazelle fügt automatisch ein data wie das obige hinzu, wenn Sie über ein testdata verfügen, es sei denn, es enthält erstellbare .go-Dateien oder Build-Dateien. In diesem Fall werden testdata als normales Paket behandelt.
Beachten Sie, dass Datendateien unter Windows nicht direkt für Tests verfügbar sind, da Testdatendateien auf symbolischen Links basieren und Windows standardmäßig nicht zulässt, dass unprivilegierte Benutzer symbolische Links erstellen. Sie können die Bibliothek github.com/bazelbuild/rules_go/go/tools/bazel verwenden, um auf Datendateien zuzugreifen.
Der Speicherort, an dem go_binary seine ausführbare Datei schreibt, ist in allen Rules_go-Versionen nicht stabil und man sollte sich nicht darauf verlassen. Der Name des übergeordneten Verzeichnisses enthält einige Konfigurationsdaten. Dies verhindert, dass der Cache von Bazel vergiftet wird, wenn dieselbe Binärdatei in unterschiedlichen Konfigurationen erstellt wird. Der binäre Basisname kann auch plattformabhängig sein: Unter Windows fügen wir eine .exe-Erweiterung hinzu.
Um von einer ausführbaren Datei in einer go_test -Regel abhängig zu sein, referenzieren Sie die ausführbare Datei im data (um sie sichtbar zu machen) und erweitern Sie dann den Speicherort in args . Der tatsächliche Standort wird in der Befehlszeile an den Test übergeben. Zum Beispiel:
go_binary (
name = "cmd" ,
srcs = [ "cmd.go" ],
)
go_test (
name = "cmd_test" ,
srcs = [ "cmd_test.go" ],
args = [ "$(location :cmd)" ],
data = [ ":cmd" ],
)Unter //tests/core/cross finden Sie ein vollständiges Beispiel für einen Test, der auf eine Binärdatei zugreift.
Alternativ können Sie das out -Attribut von go_binary auf einen bestimmten Dateinamen setzen. Beachten Sie, dass die Binärdatei beim Ändern von Konfigurationen nicht zwischengespeichert wird, wenn out festgelegt ist.
go_binary (
name = "cmd" ,
srcs = [ "cmd.go" ],
out = "cmd" ,
)
go_test (
name = "cmd_test" ,
srcs = [ "cmd_test.go" ],
data = [ ":cmd" ],
)Siehe Konflikte vermeiden in der Proto-Dokumentation.
Dies wird nicht unterstützt. Bei Verwendung von go_proto_library mit dem Compiler @io_bazel_rules_go//proto:go_grpc wird eine implizite Abhängigkeit von @org_golang_google_grpc//:go_default_library hinzugefügt. Wenn Sie eine andere Kopie desselben Pakets von //vendor/google.golang.org/grpc:go_default_library oder anderswo verlinken, kann es beim Kompilieren oder zur Laufzeit zu Konflikten kommen.
Wenn Sie Gazelle mit aktivierter Proto-Regelgenerierung verwenden, werden Importe von google.golang.org/grpc automatisch in @org_golang_google_grpc//:go_default_library aufgelöst, um Konflikte zu vermeiden. Der bereitgestellte gRPC sollte in diesem Fall ignoriert werden.
Wenn Sie speziell ein vom Anbieter bereitgestelltes gRPC-Paket verwenden müssen, vermeiden Sie am besten die Verwendung von go_proto_library ganz. Sie können vorgenerierte .pb.go-Dateien einchecken und sie mit go_library -Regeln erstellen. Gazelle generiert diese Regeln, wenn die Generierung von Proto-Regeln deaktiviert ist (fügen Sie # gazelle:proto disable_global zu Ihrer Root-Build-Datei hinzu).
Anweisungen zum Überschreiben von in go_rules_dependencies deklarierten Repositorys finden Sie unter Abhängigkeiten überschreiben.
Referenzen:
Um Bazel-Tests auf Travis CI auszuführen, müssen Sie Bazel im before_install -Skript installieren. Sehen Sie sich unsere oben verlinkte Konfigurationsdatei an.
Sie sollten Bazel mit einer Reihe von Flags ausführen, um zu verhindern, dass es in der Testumgebung viel Speicher verbraucht.
--host_jvm_args=-Xmx500m --host_jvm_args=-Xms500m : Legen Sie die maximale und anfängliche JVM-Heap-Größe fest. Wenn Sie das Gleiche beibehalten, verbringt die JVM keine Zeit damit, den Heap zu vergrößern. Die Wahl der Heap-Größe ist etwas willkürlich; Andere Konfigurationsdateien empfehlen Grenzwerte von bis zu 2500 m. Höhere Werte bedeuten einen schnelleren Build, aber ein höheres Risiko eines OOM-Kills.--bazelrc=.test-bazelrc : Verwenden Sie eine für Travis CI spezifische Bazel-Konfigurationsdatei. Die meisten der verbleibenden Optionen können Sie hier eingeben.build --spawn_strategy=standalone --genrule_strategy=standalone : Sandboxing für den Build deaktivieren. Sandboxing kann innerhalb der Travis-Container fehlschlagen, da der mount -Systemaufruf nicht zulässig ist.test --test_strategy=standalone : Sandboxing auch für Tests deaktivieren.--local_resources=1536,1.5,0.5 : Legen Sie Bazel-Grenzwerte für verfügbaren RAM in MB, verfügbare Kerne für die Datenverarbeitung und verfügbare Kerne für E/A fest. Höhere Werte bedeuten einen schnelleren Build, aber höhere Konflikte und das Risiko eines OOM-Kills.--noshow_progress : Fortschrittsmeldungen in der Ausgabe unterdrücken, um Protokolle sauberer zu machen.--verbose_failures : Erhalten Sie detailliertere Fehlermeldungen.--test_output=errors : Test stderr im Travis-Protokoll anzeigen. Normalerweise handelt es sich bei der Testausgabe um geschriebene Protokolldateien, die Travis nicht speichert oder meldet. Downloads auf Travis sind relativ langsam (das Netzwerk ist stark ausgelastet), daher sollten Sie die Menge an Netzwerk-E/A in Ihrem Build minimieren. Das Herunterladen von Bazel und einem Go SDK ist ein großer Teil davon. Um das Herunterladen eines Go SDK zu vermeiden, können Sie einen Container mit einer vorinstallierten Version von Go in Ihrer .travis.yml Datei anfordern und dann go_register_toolchains(go_version = "host") in einer Travis-spezifischen WORKSPACE Datei aufrufen.
Sie könnten versucht sein, Bazels Cache in Ihren Travis-Cache zu legen. Obwohl dies Ihren Build erheblich beschleunigen kann, speichert Travis seinen Cache bei Amazon und die Übertragung dauert sehr lange. Saubere Builds scheinen in der Praxis schneller zu sein.
Rules_go unterstützt nur offizielle Versionen des Go SDK. Sie können jedoch weiterhin Beta- und RC-Versionen testen, indem Sie eine version wie "1.16beta1" an go_register_toolchains übergeben. Siehe auch 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" )
