Kurallar
takma ad
alias(name, actual, compatible_with, deprecation, features, restricted_to, tags, target_compatible_with, testonly, visibility)
alias
kuralı, bir kural için kullanılabilecek başka bir ad oluşturur.
Takma ad, yalnızca "normal" hedefler için çalışır. Özellikle, package_group
ve test_suite
diğerlerine ad veremez.
Takma ad kuralının kendi görünürlük bildirimi vardır. Diğer tüm açılardan, referans verdiği kural gibi davranır (ör. takma addaki testonly göz ardı edilir; bunun yerine referans verilen kuralın salt test düzeyi kullanılır) ve bazı küçük istisnalar bulunur:
-
Komut satırında takma adlarından bahsediliyorsa testler çalıştırılmaz. Başvurulan testi çalıştıran bir takma ad tanımlamak için
tests
özelliğinde tek hedefi olan birtest_suite
kuralı kullanın. -
Ortam grupları tanımlanırken
environment
kurallarının takma adları desteklenmez. Bunlar--target_environment
komut satırı seçeneğinde de desteklenmez.
Örnekler
filegroup( name = "data", srcs = ["data.txt"], ) alias( name = "other", actual = ":data", )
Bağımsız değişkenler
Özellikler | |
---|---|
name |
Bu hedef için benzersiz bir ad. |
actual
|
|
config_setting
config_setting(name, constraint_values, define_values, deprecation, distribs, features, flag_values, licenses, tags, testonly, values, visibility)
Yapılandırılabilir özellikleri tetiklemek amacıyla, beklenen bir yapılandırma durumuyla (derleme bayrakları veya platform kısıtlamaları olarak ifade edilir) eşleşir. Bu kuralın nasıl kullanılacağını öğrenmek için select, genel özelliğe genel bakış için Yapılandırılabilir özelliklere bakın.
Örnekler
Aşağıdaki kod, --compilation_mode=opt
veya -c opt
değerlerini ayarlayan tüm derlemelerle eşleşir (açıkça komut satırında veya dolaylı olarak .bazelrc dosyalarından):
config_setting( name = "simple", values = {"compilation_mode": "opt"} )
Aşağıdaki, ARM'yi hedefleyen ve özel FOO=bar
tanımını uygulayan tüm derlemelerle eşleşir (örneğin, bazel build --cpu=arm --define FOO=bar ...
):
config_setting( name = "two_conditions", values = { "cpu": "arm", "define": "FOO=bar" } )
Aşağıdaki, kullanıcı tanımlı işareti
--//custom_flags:foo=1
ayarlayan (açıkça komut satırında veya dolaylı olarak .bazelrc dosyalarından) tüm derlemelerle eşleşir:
config_setting( name = "my_custom_flag_is_set", flag_values = { "//custom_flags:foo": "1" }, )
Aşağıdaki örnekte, //example:glibc_2_25
etiketine sahip bir constraint_value
bulunduğu varsayılarak x86_64 mimarisi ve glibc sürümü 2.25 olan bir platformu hedefleyen tüm derlemeler eşleştirilmektedir. Bir platformun, bu ikisinin dışında ek sınırlama değerleri tanımladığı durumlarda hâlâ eşleştirme yaptığını unutmayın.
config_setting( name = "64bit_glibc_2_25", constraint_values = [ "@platforms//cpu:x86_64", "//example:glibc_2_25", ] )Tüm bu durumlarda yapılandırmanın derleme içinde değişebilir. Örneğin, bir hedefin atamadan farklı bir platform için oluşturulması gerekiyorsa. Bu, bir
config_setting
üst düzey komut satırı işaretleriyle eşleşmediğinde bile bazı derleme hedefleriyle eşleşebileceği anlamına gelir.
Notlar
- Mevcut yapılandırma durumuyla birden fazla
config_setting
eşleştiğinde ne olacağını öğrenmek için select (seçme) bölümüne bakın. - Kısayol biçimlerini destekleyen işaretler (ör.
--compilation_mode
--c
) içinvalues
tanımlarının tam biçimi kullanması gerekir. Bunlar, formlardan herhangi birini kullanarak çağrıları otomatik olarak eşleştirir. -
Bir işaret birden fazla değer alıyorsa (
--copt=-Da --copt=-Db
veya liste türünde bir Starlark işareti gibi)"a"
gerçek listede herhangi bir yerde mevcutsavalues = { "flag": "a" }
eşleşir.values = { "myflag": "a,b" }
de aynı şekilde çalışır: Bu;--myflag=a --myflag=b
,--myflag=a --myflag=b --myflag=c
,--myflag=a,b
ve--myflag=c,b,a
ile eşleşir. Kesin anlamlar, işaretler arasında farklılık gösterir. Örneğin--copt
, aynı örnekte birden çok değeri desteklemez:--copt=a,b
,["a,b"]
değerini üretirken--copt=a --copt=b
["a", "b"]
değerini üretir (yanivalues = { "copt": "a,b" }
, ilkiyle eşleşir ancak ikincisiyle eşleşmez). Ancak--ios_multi_cpus
(Apple kuralları için) oluşturur: Hem-ios_multi_cpus=a,b
hem deios_multi_cpus=a --ios_multi_cpus=b
["a", "b"]
üretir. Beklentileri tam olarak doğrulamak için işaret tanımlarını kontrol edin ve koşullarınızı dikkatli bir şekilde test edin. - Yerleşik derleme işaretleri tarafından modellenmemiş koşullar tanımlamanız gerekiyorsa
Starlark tarafından tanımlanan işaretleri kullanın.
--define
yöntemini de kullanabilirsiniz ancak bu yöntem daha zayıf destek sağladığından önerilmez. Daha fazla bilgi için buraya göz atın. config_setting
tanımlarını farklı paketlerde tekrarlamaktan kaçının. Bunun yerine, standart pakette tanımlanan ortak birconfig_setting
öğesine referans verin.values
,define_values
veconstraint_values
aynıconfig_setting
içindeki herhangi bir kombinasyonda kullanılabilir ancak belirli herhangi birconfig_setting
için en az bir kombinasyon ayarlanmalıdır.
Bağımsız değişkenler
Özellikler | |
---|---|
name |
Bu hedef için benzersiz bir ad. |
constraint_values
|
config_setting ile eşleşmesi için hedef platformun belirtmesi gereken minimum constraint_values grubu. (Yürütme platformu burada dikkate alınmaz.) Platformun sahip olduğu ek kısıtlama değerleri yok sayılır. Ayrıntılar için
Yapılandırılabilir Derleme Özellikleri bölümüne bakın.
İki |
define_values
|
values ile aynıdır, ancak özellikle --define işareti için geçerlidir.
Bu durumda: config_setting( name = "a_and_b", values = { "define": "a=1", "define": "b=2", }) çalışmaz. Çünkü aynı anahtar ( config_setting( name = "a_and_b", define_values = { "a": "1", "b": "2", })
|
flag_values
|
values ile aynıdır, ancak
kullanıcı tanımlı derleme işaretleri için geçerlidir.
Bu ayrı bir özelliktir. Çünkü kullanıcı tanımlı işaretlere etiket olarak, yerleşik flag'lere ise rastgele dizelere başvurulur. |
values
|
Bu kural, Kolaylık sağlamak amacıyla, yapılandırma değerleri derleme bayrağı olarak belirtilir (önceki Bir işaret, komut satırında açıkça ayarlanmazsa varsayılan değeri kullanılır.
Bir anahtar, sözlükte birden çok kez görünürse yalnızca sonuncu örneği kullanılır.
Bir anahtar, komut satırında birden çok kez ayarlanabilen bir işarete referans veriyorsa (ör.
|
dosya grubu
filegroup(name, srcs, data, compatible_with, deprecation, distribs, features, licenses, output_group, restricted_to, tags, target_compatible_with, testonly, visibility)
Hedef koleksiyonuna kullanışlı bir ad vermek için filegroup
kullanın.
Daha sonra bunlara diğer kurallardan referans verilebilir.
Doğrudan dizinlere referans vermek yerine filegroup
kullanılması önerilir.
İkinci yöntem, derleme sistemi dizin altındaki tüm dosyalar hakkında tam bilgiye sahip olmadığından bir çözüm bulmaz. Bu nedenle, bu dosyalar değiştiğinde yeniden oluşturmayabilir. filegroup
, glob ile birlikte kullanıldığında tüm dosyaların derleme sistemi tarafından açıkça bilinmesini sağlayabilir.
Örnekler
İki kaynak dosyadan oluşan bir filegroup
oluşturmak için şunu yapın:
filegroup( name = "mygroup", srcs = [ "a_file.txt", "some/subdirectory/another_file.txt", ], )
Veya bir testdata dizinini görüntülemek için glob
kullanın:
filegroup( name = "exported_testdata", srcs = glob([ "testdata/*.dat", "testdata/logs/**/*.log", ]), )
Bu tanımlardan yararlanmak için herhangi bir kuraldan bir etiketle filegroup
referansına başvurun:
cc_library( name = "my_library", srcs = ["foo.cc"], data = [ "//my_package:exported_testdata", "//my_package:mygroup", ], )
Bağımsız değişkenler
Özellikler | |
---|---|
name |
Bu hedef için benzersiz bir ad. |
srcs
|
|
data
|
|
output_group
|
"Çıkış grubu", kuralın uygulamasında belirtilen, hedefin çıkış yapıları kategorisidir. |
Genquery
genquery(name, deps, data, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, expression, features, licenses, opts, restricted_to, scope, strict, tags, target_compatible_with, testonly, visibility)
genquery()
, Blaze sorgu dilinde belirtilen bir sorguyu çalıştırır ve sonucu bir dosyaya atar.
Derlemenin tutarlı kalması için sorgunun yalnızca scope
özelliğinde belirtilen hedeflerin geçişli olarak kapanmasını ziyaret etmesine izin verilir. strict
belirtilmemişse veya doğru değerine ayarlanırsa bu kuralı ihlal eden sorgular, yürütme sırasında başarısız olur (strict
değeri yanlışsa kapsam dışı hedefler bir uyarıyla atlanır). Bunun olmamasını sağlamanın en kolay yolu, sorgu ifadesindekiyle aynı etiketleri kapsamda belirtmektir.
Burada ve komut satırında izin verilen sorgular arasındaki tek fark, joker karakter hedef özelliklerini (ör. //pkg:*
veya //pkg:all
) içeren sorgulara burada izin verilmemesidir.
Bunun iki nedeni vardır: Birincisi, genquery
ürününün çıktısını etkilemek için sorgunun geçişli kapanması dışındaki hedefleri engellemek için bir kapsam belirtmesi gerekir.İkincisi, BUILD
dosyaları joker karakter bağımlılıklarını desteklemediğinden (ör. deps=["//a/..."]
değerine izin verilmez).
Genquery'nin çıkışı, belirleyici çıkışı uygulamak için --order_output=full
kullanılarak sıralanır.
Çıkış dosyasının adı kuralın adıdır.
Örnekler
Bu örnekte, belirtilen hedefin geçişli kapanışındaki etiketlerin listesi bir dosyaya yazılır.
genquery( name = "kiwi-deps", expression = "deps(//kiwi:kiwi_lib)", scope = ["//kiwi:kiwi_lib"], )
Bağımsız değişkenler
Özellikler | |
---|---|
name |
Bu hedef için benzersiz bir ad. |
expression
|
a/BUILD dosyasındaki bu özellikte yer alan :b etiketi, //:b hedefine referans verir.
|
opts
|
bazel query işlevine iletilebilecek komut satırı seçeneklerine karşılık gelir. Burada bazı sorgu seçeneklerine izin verilmez: --keep_going , --query_file , --universe_scope , --order_results ve --order_output . Burada belirtilmeyen seçeneklerin, bazel query komut satırında olduğu gibi varsayılan değerleri olur.
|
scope
|
|
strict
|
|
Genrule
genrule(name, srcs, outs, cmd, cmd_bash, cmd_bat, cmd_ps, compatible_with, deprecation, distribs, exec_compatible_with, exec_properties, exec_tools, executable, features, licenses, local, message, output_licenses, output_to_bindir, restricted_to, tags, target_compatible_with, testonly, toolchains, tools, visibility)
genrule
, kullanıcı tanımlı Bash komutu kullanarak bir veya daha fazla dosya oluşturur.
Kurallar, görev için belirli bir kural olmadığında kullanabileceğiniz genel derleme kurallarıdır.
Örneğin, bir Bash tek satırlı metin yazabilirsiniz. Ancak C++ dosyalarını derlemeniz gerekiyorsa mevcut cc_*
kurallarına bağlı kalın. İşin zor kısmını zaten sizin yerinize yapmışsınızdır.
Test çalıştırmak için genrule kullanmayın. Test ve test sonuçları için önbelleğe alma politikaları ve ortam değişkenleri de dahil olmak üzere özel dağıtımlar vardır. Testlerin genellikle derleme tamamlandıktan sonra ve hedef mimaride çalıştırılması gerekir. Kurallar, derleme sırasında ve ana makine mimarisinde yürütülür (ikisi farklı olabilir). Genel amaçlı test kuralına ihtiyacınız varsa sh_test
kullanın.
Çapraz Derleme Hakkında Dikkat Edilmesi Gerekenler
Çapraz derleme hakkında daha fazla bilgi için kullanıcı kılavuzuna bakın.
Genel kurallar bir derleme sırasında çalışır ancak çıkışları genellikle derlemeden sonra dağıtım veya test için kullanılır. Bir mikro denetleyici için C kodu derleme örneğini düşünün: Derleyici, C kaynak dosyalarını kabul eder ve bir mikrodenetleyici üzerinde çalışan kod oluşturur. Oluşturulan kod açıkça bu CPU'yu oluşturmak için kullanılan CPU'da çalışamaz, ancak C derleyicisinin (kaynaktan derlenmişse) bunu yapması gerekir.
Derleme sistemi, derlemenin çalıştığı makineleri tanımlamak için ana makine yapılandırmasını, derleme çıktısının çalışması gereken makineleri tanımlamak için ise hedef yapılandırmayı kullanır. Bunların her birini yapılandırmak için seçenekler sunar ve çakışmaları önlemek için ilgili dosyaları ayrı dizinlere ayırır.
Genrules için derleme sistemi, bağımlılıkların uygun şekilde derlendiğinden emin olur: target yapılandırması için srcs
oluşturulur (gerekirse), tools
host yapılandırması için oluşturulur ve çıkışın target yapılandırması için olduğu kabul edilir. Ayrıca, genel komutların ilgili araçlara geçirebileceği
"Oluştur" değişkenleri de sağlar.
Genrule için herhangi bir deps
özelliği tanımlanmamıştır. Diğer yerleşik kurallar, bağımlı kuralların nasıl ele alınacağını otomatik olarak belirlemek için kurallar arasında iletilen dile bağlı meta bilgileri kullanır. Ancak bu düzeyde bir otomasyon, Genrules için mümkün değildir. Genel kurallar yalnızca dosya ve çalıştırma dosyaları düzeyinde çalışır.
Özel Durumlar
Ana makine-ana makine derlemesi: Bazı durumlarda derleme sisteminin, çıkışın derleme sırasında da yürütülebilmesi için
türler çalıştırması gerekir. Örneğin, bir genrule, daha sonra başka bir tür tarafından kullanılacak olan bir özel derleyici oluşturursa ilkinin, ana makine yapılandırması için çıktısını oluşturması gerekir çünkü derleyici diğer genrule'da burada çalışır. Bu durumda derleme sistemi doğru olanı otomatik olarak yapar: Hedef yapılandırma yerine ana makine yapılandırması için birinci türünün srcs
ve outs
öğelerini oluşturur. Daha fazla bilgi için kullanım kılavuzuna bakın.
JDK ve C++ Araçları: JDK veya C++ derleyici paketinden bir araç kullanmak için derleme sistemi, kullanılacak bir dizi değişken sağlar. Ayrıntılar için "Marka" değişkenine bakın.
Genrule Ortam
Genrule komutu, bir komut veya ardışık düzen başarısız olduğunda set -e -o pipefail
kullanılarak başarısız olacak şekilde yapılandırılan Bash kabuğu tarafından çalıştırılır.
Derleme aracı, Bash komutunu yalnızca PATH
, PWD
, TMPDIR
ve diğer birkaç temel değişkeni tanımlayan arındırılmış işlem ortamında yürütür.
Derlemelerin yeniden oluşturulabilir olduğundan emin olmak için kullanıcının kabuk ortamında tanımlanan çoğu değişken, genrule komutuna iletilmez. Bununla birlikte, Bazel (Blaze değil) kullanıcının PATH
ortam değişkeninin değerini geçirir.
PATH
değerindeki herhangi bir değişiklik, Bazel'ın bir sonraki derlemede komutu yeniden çalıştırmasına neden olur.
genrule komutu, şu anda zorunlu olmasa da komutun alt öğesi olan işlemleri bağlamak dışında ağa erişmemelidir.
Derleme sistemi, mevcut çıkış dosyalarını otomatik olarak siler, ancak bir genel kuralı çalıştırmadan önce gerekli üst dizinleri oluşturur. Ayrıca, hata durumunda tüm çıkış dosyalarını kaldırır.
Genel Tavsiye
- Ciddi bir kural tarafından yönetilen araçların deterministik ve hermetik olduğundan emin olun. Çıkışlarına zaman damgaları yazmamalı, kümeler ve haritalar için sabit sıralama kullanmalı, mutlak yol olmamalı ve çıkışa yalnızca göreli dosya yolları yazmalıdırlar. Bu kurala uyulmaması, beklenmeyen bir derleme davranışına (Bazel'in düşündüğünüz bir biçimi yeniden oluşturmamasına) neden olur ve önbellek performansını düşürür.
- Çıktılar, araçlar ve kaynaklar için
$(location)
uygulamasını yaygın olarak kullanın. Çıkış dosyalarının farklı yapılandırmalar için ayrılması nedeniyle, türler sabit kodlu ve/veya mutlak yollara dayanamaz. - Birden çok yerde aynı veya çok benzer türlerin kullanılması ihtimaline karşı ortak bir Starlark makrosu yazın. Genrule karmaşıksa bunu bir komut dosyası veya Starlark kuralı olarak uygulamayı düşünebilirsiniz. Bu, okunabilirliği ve test edilebilirliği iyileştirir.
- Çıkış kodunun, oluşturma işleminin başarılı veya başarısız olduğunu doğru bir şekilde belirttiğinden emin olun.
- stdout veya stderr'a bilgilendirici iletiler yazmayın. Bu, hata ayıklama açısından faydalı olsa da kolayca gürültüye dönüşebilir. Başarılı bir oluşturma işlemi sessiz olmalıdır. Öte yandan başarısız bir nazik davranış, iyi hata mesajları vermelidir.
$$
evaluates to a$
, a literal dollar-sign, so in order to invoke a shell command containing dollar-signs such asls $(dirname $x)
, one must escape it thus:ls $$(dirname $$x)
.- Simgesel bağlantılar ve dizinler oluşturmaktan kaçının. Bazel, Genrules tarafından oluşturulan dizin/sembolik bağlantı yapısını kopyalamaz ve dizinlerin bağımlılık denetimi güvenilir değildir.
- Diğer kurallarda genrule özelliğine referans verirken genrule etiketini veya bağımsız çıkış dosyalarının etiketlerini kullanabilirsiniz. Bazen bir yaklaşım daha okunabilir, bazen de diğer: bir tüketim kuralının
srcs
öğesinde çıktılara adla atıfta bulunmak, genrule türünün diğer çıktılarını istemeden almaktan kaçınır, ancak genrule çok sayıda sonuç üretiyorsa yorucu olabilir.
Örnekler
Bu örnek, foo.h
sonucunu oluşturur. Komut herhangi bir giriş almadığı için kaynak yok. Komutun çalıştırdığı "binary", genrule ile aynı pakette bulunan bir perl komut dosyasıdır.
genrule( name = "foo", srcs = [], outs = ["foo.h"], cmd = "./$(location create_foo.pl) > \"$@\"", tools = ["create_foo.pl"], )
Aşağıdaki örnekte, bir filegroup
öğesinin nasıl kullanılacağı ve başka bir genrule
öğesinin sonuçları gösterilmektedir. Açık $(location)
yönergeleri yerine $(SRCS)
kullanmanın da işe yarayacağını unutmayın. Bu örnekte göstermek amacıyla ikinci kural kullanılmıştır.
genrule( name = "concat_all_files", srcs = [ "//some:files", # a filegroup with multiple files in it ==> $(locations) "//other:gen", # a genrule with a single output ==> $(location) ], outs = ["concatenated.txt"], cmd = "cat $(locations //some:files) $(location //other:gen) > $@", )
Bağımsız değişkenler
Özellikler | |
---|---|
name |
Bu hedef için benzersiz bir ad. Bu kurala, diğer BUILD kurallarının srcs veya deps bölümünde adıyla başvurabilirsiniz. Kural, kaynak dosyalar oluşturuyorsa srcs özelliğini kullanmanız gerekir.
|
srcs
|
Bu özellikler,
Derleme sistemi, genel komutunu çalıştırmadan önce bu önkoşulların derlenmesini sağlar. Bunlar, orijinal derleme isteğiyle aynı yapılandırma kullanılarak derlenir. Bu önkoşullara sahip dosyaların adları, komutta |
outs
|
Çıktı dosyaları paket sınırlarını aşmamalıdır. Çıkış dosya adları pakete göre yorumlanır.
Genrule komutunun her çıkış dosyasını önceden belirlenmiş bir konumda oluşturması beklenir.
Konum, |
cmd
|
$(location)
ve "Değişken yap" değişikliğine tabidir.
cmd_bash , cmd_ps ve cmd_bat yedekleridir.
Komut satırı uzunluğu platform sınırını aşarsa (Linux/macOS'te 64K, Windows'da 8K) genrule komutu bir komut dosyasına yazar ve geçici çözüm için o komut dosyasını yürütür. Bu, tüm cmd özellikleri ( |
cmd_bash
|
Bu özellik, |
cmd_bat
|
Bu özellik,
|
cmd_ps
|
Bu özellik
Powershell'in kullanımını kolaylaştırmak ve hataya daha az açık olması için aşağıdaki komutları çalıştırarak Powershell komutunu genrule'da çalıştırmadan önce ortamı ayarlıyoruz.
|
exec_tools
|
tools özelliğiyle aynı şekilde davranır.
Yani exec_tools içindeki bağımlılıklar, tools hizmetindeki bağımlılıklarla aynı sınırlamalara tabi değildir. Özellikle kendi geçişli bağımlılıkları için ana makine yapılandırmasını kullanmaları gerekmez. Daha fazla bilgi için tools sayfasını inceleyin.
Blaze ekibi, tüm |
executable
|
Bu işaretin True (Doğru) değerine ayarlanması, çıkışın yürütülebilir bir dosya olduğu ve Oluşturulan yürütülebilir dosya için veri bağımlılıklarının bildirilmesi desteklenmiyor. |
local
|
True (Doğru) değerine ayarlanırsa bu seçenek, bu
Bu, etiket ( |
message
|
Bu derleme adımı yürütüldüğünde yazdırılacak bir ilerleme mesajı. Varsayılan olarak, mesaj "çıktı oluşturuluyor" (veya eşit derecede sıkıcı bir mesaj) şeklindedir ancak daha spesifik bir mesaj sağlayabilirsiniz. Bu özelliği, derleme aracının bu ilerleme mesajlarının yazdırılıp yazdırılmayacağını kontrol etmesine olanak tanımak için |
output_licenses
|
common attributes
|
output_to_bindir
|
Doğru değerine ayarlanırsa bu seçenek, çıkış dosyalarının |
tools
|
Derleme sistemi, bu ön koşulların genel komutunu çalıştırmadan önce derlenmesini sağlar. Bu araçlar derlemenin parçası olarak yürütüldüğü için host yapılandırması kullanılarak oluşturulur. Tek bir
|
test_suite
test_suite(name, compatible_with, deprecation, distribs, features, licenses, restricted_to, tags, target_compatible_with, testonly, tests, visibility)
test_suite
, insanlar için "yararlı" olarak kabul edilen bir dizi testi tanımlar. Bu sayede projeler, "kontrol sürecinden önce çalıştırmanız gereken testler", "projemizin stres testleri" veya "tüm küçük testler" gibi test kümeleri tanımlayabilir. blaze test
komutu bu tür bir organizasyona uyar: blaze test //some/test:suite
gibi bir çağrıda Blaze, öncelikle //some/test:suite
hedefi tarafından geçişli olarak eklenen tüm test hedeflerini numaralandırır (buna "test_suite genişletmesi" denir) ve daha sonra Blaze bu hedefleri oluşturup test eder.
Örnekler
Mevcut paketteki tüm küçük testleri çalıştırmak için kullanılan bir test paketi.
test_suite( name = "small_tests", tags = ["small"], )
Belirli bir test grubunu çalıştıran test paketi:
test_suite( name = "smoke_tests", tests = [ "system_unittest", "public_api_unittest", ], )
Mevcut pakette güvenilir olmayan tüm testleri çalıştırmak için kullanılan bir test paketi.
test_suite( name = "non_flaky_test", tags = ["-flaky"], )
Bağımsız değişkenler
Özellikler | |
---|---|
name |
Bu hedef için benzersiz bir ad. |
tags
|
"-" karakteriyle başlayan etiketler negatif etiket olarak kabul edilir. Öncesindeki "-" karakteri, etiketin bir parçası olarak kabul edilmez. Bu nedenle, "-small" paketinin etiketi bir testin "small" boyutuyla eşleşir. Diğer tüm etiketler pozitif etiket olarak kabul edilir. İsteğe bağlı olarak, pozitif etiketleri daha açık hale getirmek için etiketler "+" karakteriyle de başlayabilir. Bu, etiket metninin bir parçası olarak değerlendirilmez. Yalnızca pozitif ve negatif ayrımların daha kolay okunmasını sağlar. Yalnızca pozitif etiketlerin tümü ile eşleşen ve negatif etiketlerin hiçbiri ile eşleşen test kuralları test paketine dahil edilir. Bunun, filtrelenen testlerdeki bağımlılıklar için hata kontrolünün atlandığı anlamına gelmediğini unutmayın.Atlanan testlere olan bağımlılıkların yine de yasal olması gerekir (ör. görünürlük kısıtlamaları tarafından engellenmemelidir).
Testin
Karşılıklı birbirini dışlayan etiketler (ör. tüm küçük ve orta testler) içeren testler içeren bir |
tests
|
Dilden bağımsız olarak tüm
|