Rules_go
v0.50.1
القائمة البريدية: مناقشة بازل
Slack: #انطلق على Bazel Slack، #bazel على Go Slack
القواعد في مرحلة بيتا من التطوير. إنهم يدعمون:
إنهم لا يدعمون حاليًا أو لديهم دعم محدود لما يلي:
يتم اختبار قواعد Go ودعمها على الأنظمة الأساسية المضيفة التالية:
أبلغ المستخدمون عن نجاحهم على العديد من الأنظمة الأساسية الأخرى، ولكن يتم اختبار القواعد فقط على تلك المذكورة أعلاه.
ملاحظة: منذ الإصدار v0.38.0، تتطلب القواعد_go وجود Bazel ≥ 5.4.0 للعمل.
الفرع master مضمون فقط للعمل مع أحدث إصدار من Bazel.
لإنشاء كود Go باستخدام Bazel، ستحتاج إلى:
patch و cat وحفنة من أدوات Unix الأخرى في PATH .لن تحتاج عادةً إلى تثبيت سلسلة أدوات Go. سيقوم بازل بتنزيل واحدة.
راجع استخدام القواعد_go على نظام التشغيل Windows للحصول على إرشادات الإعداد الخاصة بنظام التشغيل Windows. يجب تثبيت وتكوين العديد من الأدوات الإضافية.
إذا كنت تستخدم نظام إدارة التبعية الخارجية الجديد Bzlmod من Bazel، فارجع إلى دليل Go with Bzlmod المخصص بدلاً من ذلك.
أنشئ ملفًا في أعلى مستودعك باسم WORKSPACE ، وأضف المقتطف أدناه (أو أضفه إلى WORKSPACE الموجود لديك). هذا يخبر Bazel بإحضار القواعد_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" ) يمكنك استخدام القواعد_go على master باستخدام git_repository بدلاً من http_archive والإشارة إلى الالتزام الأخير.
أضف ملفًا باسم 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 سيؤدي هذا إلى إنشاء ملف BUILD.bazel يتضمن أهداف go_library وgo_binary وgo_test لكل حزمة في مشروعك. يمكنك تشغيل نفس الأمر في المستقبل لتحديث ملفات البناء الموجودة بملفات مصدر وتبعيات وخيارات جديدة.
إذا كان مشروعك لا يتبع قواعد go build أو كنت تفضل عدم استخدام Gazelle، فيمكنك كتابة ملفات البناء يدويًا.
في كل دليل يحتوي على كود Go، أنشئ ملفًا باسم BUILD.bazel وأضف بيان load في أعلى الملف للقواعد التي تستخدمها.
load ( "@io_bazel_rules_go//go:def.bzl" , "go_binary" , "go_library" , "go_test" ) لكل مكتبة، قم بإضافة قاعدة go_library مثل تلك الموجودة أدناه. يتم سرد الملفات المصدر في سمة srcs . يتم إدراج الحزم المستوردة خارج المكتبة القياسية في السمة deps باستخدام تسميات Bazel التي تشير إلى قواعد go_library المقابلة. يجب تحديد مسار استيراد المكتبة باستخدام سمة 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 ()ستحتاج إلى سلسلة أدوات C/C++ مسجلة لمنصة التنفيذ (النظام الأساسي حيث يقوم Bazel بتشغيل الإجراءات) لإنشاء البروتوكول.
يتم توفير قاعدة proto_library بواسطة مستودع rules_proto . يتم توفير protoc-gen-go ، وهو البرنامج المساعد للمترجم Go proto، من خلال مستودع com_github_golang_protobuf . تم الإعلان عن كلاهما بواسطة go_rules_dependeency. لن تحتاج إلى الإعلان عن تبعية صريحة إلا إذا كنت تريد على وجه التحديد استخدام إصدار مختلف. راجع تجاوز التبعيات للحصول على إرشادات حول استخدام إصدار مختلف.
لا يتم الإعلان عن تبعيات gRPC افتراضيًا (هناك الكثير منها). يمكنك الإعلان عنها في WORKSPACE باستخدام go_repository. قد ترغب في استخدام Gazelle Update-Repos لاستيرادها من go.mod .
راجع تبعيات Proto وتبعيات gRPC لمزيد من المعلومات. انظر أيضًا تجنب الصراعات.
بمجرد تسجيل جميع التبعيات، يمكنك إعلان قواعد proto_library وgo_proto_library لإنشاء وتجميع كود Go من ملفات .proto.
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 العادي.
لاحظ أن الإصدارات الحديثة من القواعد_go تدعم كلاً من APIv1 ( github.com/golang/protobuf ) وAPIv2 ( google.golang.org/protobuf ). افتراضيًا، يتم إنشاء التعليمات البرمجية باستخدام github.com/golang/protobuf/cmd/protoc-gen-gen للتوافق مع كلتا الواجهتين. يمكن استيراد رمز العميل لاستخدام مكتبة وقت التشغيل أو كليهما.
يذهب
المخازن المؤقتة للبروتوكول
التبعيات والاختبار
نعم، ولكن ليس بشكل مباشر.
تستدعي القواعد_go مترجم Go والرابط مباشرةً، استنادًا إلى الأهداف الموضحة في go_binary والقواعد الأخرى. يقوم كل من Bazel وrules_go معًا بنفس الدور الذي يقوم به الأمر go ، لذلك ليس من الضروري استخدام الأمر go في مساحة عمل Bazel.
ومع ذلك، لا يزال من الجيد عادةً اتباع الاصطلاحات التي يتطلبها الأمر go (على سبيل المثال، حزمة واحدة لكل دليل، ومسارات الحزمة تطابق مسارات الدليل). ستظل الأدوات غير المتوافقة مع Bazel تعمل، ويمكن أن يعتمد مشروعك على مشاريع غير تابعة لـ Bazel.
إذا كنت بحاجة إلى استخدام الأمر go لتنفيذ المهام التي لا يغطيها Bazel (مثل إضافة تبعية جديدة إلى go.mod )، فيمكنك استخدام استدعاء Bazel التالي لتشغيل ثنائي go الخاص بـ Go SDK التي تم تكوينها بواسطة Bazel:
bazel run @io_bazel_rules_go//go -- < args > يُفضل هذا على تشغيل go مباشرة لأنه يضمن أن إصدار Go مطابق للإصدار الذي تستخدمه القواعد_go.
نعم، ولكن ليس بشكل مباشر. يتجاهل Bazel ملفات go.mod ، ويجب التعبير عن جميع تبعيات الحزمة من خلال سمات deps في الأهداف الموضحة في go_library والقواعد الأخرى.
يمكنك تنزيل وحدة Go في إصدار محدد كمستودع خارجي باستخدام go_repository، وهي قاعدة مساحة عمل توفرها غازيل. سيؤدي هذا أيضًا إلى إنشاء ملفات البناء باستخدام Gazelle.
يمكنك استيراد قواعد go_repository من ملف go.mod باستخدام Gazelle Update-Repos.
تم استخدام هذا للحفاظ على اتساق مسارات الاستيراد في المكتبات التي يمكن إنشاؤها باستخدام go build قبل توفر سمة importpath .
من أجل التجميع والربط بشكل صحيح، يجب أن تعرف القواعد_go مسار استيراد Go (السلسلة التي يمكن استيراد الحزمة من خلالها) لكل مكتبة. تم الآن تعيين هذا بشكل صريح باستخدام سمة importpath . قبل وجود هذه السمة، تم استنتاج مسار الاستيراد عن طريق تسلسل سلسلة من قاعدة go_prefix الخاصة وحزمة المكتبة واسم التسمية. على سبيل المثال، إذا كانت go_prefix هي github.com/example/project ، بالنسبة للمكتبة //foo/bar:bar ، فإن القواعد_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 في سطر الأوامر. على سبيل المثال:
بناء بازل $ --platforms=@io_bazel_rules_go//go/toolchain:linux_amd64 //cmd
بشكل افتراضي، يتم تعطيل cgo عند الترجمة المتداخلة. للترجمة المتداخلة مع cgo، أضف لاحقة _cgo إلى النظام الأساسي المستهدف. يجب عليك تسجيل سلسلة أدوات 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 على تلك القاعدة.
يمكنك الاعتماد بشكل مكافئ على قاعدة go_binary أو go_test من خلال انتقال تكوين Bazel على //command_line_option:platforms (هناك مشاكل في هذا الأسلوب قبل القواعد_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" ,
) افتراضيًا، يتم تشغيل الاختبارات في دليل ملف البناء الذي قام بتعريفها. لاحظ أن هذا يتبع اصطلاح اختبار Go، وليس اصطلاح Bazel الذي تتبعه اللغات الأخرى، والتي تعمل في جذر المستودع. هذا يعني أنه يمكنك الوصول إلى ملفات الاختبار باستخدام المسارات النسبية. يمكنك تغيير دليل الاختبار باستخدام السمة rundir . راجع go_test.
ستضيف Gazelle تلقائيًا سمة data مثل تلك المذكورة أعلاه إذا كان لديك دليل testdata ما لم يكن يحتوي على ملفات .go قابلة للبناء أو ملفات إنشاء، وفي هذه الحالة، يتم التعامل مع testdata كحزمة عادية.
لاحظ أنه في نظام التشغيل Windows، لا تكون ملفات البيانات متاحة مباشرة للاختبارات، نظرًا لأن ملفات بيانات الاختبار تعتمد على روابط رمزية، وبشكل افتراضي، لا يسمح Windows للمستخدمين غير المميزين بإنشاء روابط رمزية. يمكنك استخدام مكتبة github.com/bazelbuild/rules_go/go/tools/bazel للوصول إلى ملفات البيانات.
الموقع الذي يكتب فيه go_binary الملف القابل للتنفيذ غير مستقر عبر إصدارات Rules_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 للحصول على مثال كامل للاختبار الذي يصل إلى ملف ثنائي.
وبدلاً من ذلك، يمكنك تعيين السمة out الخاصة بـ go_binary لاسم ملف محدد. لاحظ أنه عند تعيين out ، لن يتم تخزين الملف الثنائي مؤقتًا عند تغيير التكوينات.
go_binary (
name = "cmd" ,
srcs = [ "cmd.go" ],
out = "cmd" ,
)
go_test (
name = "cmd_test" ,
srcs = [ "cmd_test.go" ],
data = [ ":cmd" ],
)راجع تجنب التعارضات في الوثائق الأولية.
هذا غير معتمد. عند استخدام go_proto_library مع المترجم @io_bazel_rules_go//proto:go_grpc ، تتم إضافة تبعية ضمنية على @org_golang_google_grpc//:go_default_library . إذا قمت بربط نسخة أخرى من نفس الحزمة من //vendor/google.golang.org/grpc:go_default_library أو في أي مكان آخر، فقد تواجه تعارضات أثناء الترجمة أو وقت التشغيل.
إذا كنت تستخدم Gazelle مع تمكين إنشاء القواعد الأولية، فسيتم حل عمليات استيراد google.golang.org/grpc تلقائيًا إلى @org_golang_google_grpc//:go_default_library لتجنب التعارضات. يجب تجاهل gRPC المورّد في هذه الحالة.
إذا كنت بحاجة على وجه التحديد إلى استخدام حزمة gRPC الموردة، فمن الأفضل تجنب استخدام go_proto_library تمامًا. يمكنك التحقق من ملفات .pb.go التي تم إنشاؤها مسبقًا وإنشائها باستخدام قواعد go_library . ستقوم Gazelle بإنشاء هذه القواعد عندما يتم تعطيل إنشاء القاعدة الأولية (أضف # gazelle:proto disable_global إلى ملف البناء الجذري الخاص بك).
راجع تجاوز التبعيات للحصول على تعليمات حول تجاوز المستودعات المعلنة في go_rules_dependeency.
مراجع:
لتشغيل اختبارات Bazel على Travis CI، ستحتاج إلى تثبيت Bazel في البرنامج النصي before_install . انظر ملف التكوين الخاص بنا المرتبط أعلاه.
ستحتاج إلى تشغيل Bazel بعدد من العلامات لمنعه من استهلاك قدر كبير من الذاكرة في بيئة الاختبار.
--host_jvm_args=-Xmx500m --host_jvm_args=-Xms500m : قم بتعيين الحد الأقصى والأولي لحجم كومة JVM. الحفاظ على نفس الشيء يعني أن JVM لن يقضي وقتًا في تنمية الكومة. اختيار حجم الكومة عشوائي إلى حد ما؛ توصي ملفات التكوين الأخرى بحدود تصل إلى 2500 متر. القيم الأعلى تعني بناء أسرع، ولكن خطر قتل OOM أعلى.--bazelrc=.test-bazelrc : استخدم ملف تكوين Bazel الخاص بـ Travis CI. يمكنك وضع معظم الخيارات المتبقية هنا.build --spawn_strategy=standalone --genrule_strategy=standalone : قم بتعطيل وضع الحماية للإنشاء. قد يفشل وضع الحماية داخل حاويات Travis لأن استدعاء نظام mount غير مسموح به.test --test_strategy=standalone : قم بتعطيل وضع الحماية للاختبارات أيضًا.--local_resources=1536,1.5,0.5 : قم بتعيين حدود Bazel على ذاكرة الوصول العشوائي المتوفرة بالميجابايت، والنوى المتاحة للحساب، والنوى المتاحة للإدخال/الإخراج. القيم الأعلى تعني بناء أسرع، ولكن التنافس العالي وخطر قتل OOM.--noshow_progress : منع رسائل التقدم في الإخراج للحصول على سجلات أكثر نظافة.--verbose_failures : احصل على رسائل فشل أكثر تفصيلاً.--test_output=errors : إظهار اختبار stderr في سجل Travis. عادةً ما تكون مخرجات الاختبار عبارة عن ملفات سجل مكتوبة لا يحفظها ترافيس أو يبلغ عنها. التنزيلات على Travis بطيئة نسبيًا (هناك منافسة شديدة على الشبكة)، لذا ستحتاج إلى تقليل كمية الإدخال/الإخراج للشبكة في جهازك. يعد تنزيل Bazel وGo SDK جزءًا كبيرًا من ذلك. لتجنب تنزيل Go SDK، يمكنك طلب حاوية تحتوي على إصدار مثبت مسبقًا من Go في ملف .travis.yml ، ثم الاتصال بـ go_register_toolchains(go_version = "host") في ملف WORKSPACE خاص بـ Travis.
قد تميل إلى وضع ذاكرة التخزين المؤقت الخاصة بـ Bazel في ذاكرة التخزين المؤقت الخاصة بـ Travis. على الرغم من أن هذا قد يؤدي إلى تسريع عملية البناء بشكل كبير، إلا أن Travis يقوم بتخزين ذاكرة التخزين المؤقت الخاصة به على Amazon، ويستغرق النقل وقتًا طويلاً جدًا. تبدو التصميمات النظيفة أسرع في الممارسة العملية.
Rules_go تدعم فقط الإصدارات الرسمية من Go SDK. ومع ذلك، لا يزال بإمكانك اختبار الإصدارات التجريبية وRC عن طريق تمرير version مثل "1.16beta1" إلى go_register_toolchains. راجع أيضًا 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" )
