Kod Deposu Kuralları

Sorun bildirme Kaynağı görüntüleme Nightly · 7.4 . 7.3 · 7,2 · 7,1 · 7,0 · 6,5

Bu sayfada, depo kurallarının nasıl oluşturulacağı ele alınmakta ve daha fazla bilgi için örnekler verilmektedir.

Harici depolama alanı, yalnızca WORKSPACE dosyasında kullanılabilen ve Bazel'in yükleme aşamasında hermetik olmayan işlemi etkinleştiren bir kuraldır. Her harici depo kuralı, kendi çalışma alanını ve BUILD dosyalarına ve yapısına sahip olabilir. Bunlar, üçüncü taraf kitaplıklara (Maven paketlenmiş kitaplıkları gibi) bağımlı olmak için kullanılabilir ancak Bazel'in çalıştığı ana makineye özel BUILD dosyaları oluşturmak için de kullanılabilir.

Depo kuralı oluşturma

.bzl dosyasında Yeni bir kod oluşturmak için repository_rule kod deposu kuralına ekleyin ve bunu bir genel değişkende depolayın.

Özel depo kuralı, yerel depo kuralı gibi kullanılabilir. Google zorunlu bir name özelliğine ve derleme dosyalarında bulunan her hedefe sahiptir @<name>//package:target olarak ifade edilebilir. Burada <name>, name özelliği için de kullanılmaktadır.

Kural, açıkça derlediğinizde yüklenir. seçeceğim. Bu durumda Bazel, implementation işlevini yürütür. Bu fonksiyonunda kod deposunun, içeriğinin ve BUILD dosyalarının nasıl oluşturulacağını açıklanır.

Özellikler

Özellik, attrs kural bağımsız değişkenine sözlük olarak iletilen kural bağımsız değişkenleridir. Bir depo kuralı tanımladığınızda, tanımlanan özellikler ve türleri listelenir. url ve sha256 özelliklerini strings:

local_repository = repository_rule(
    implementation=_impl,
    local=True,
    attrs={
        "url": attr.string(mandatory=True)
        "sha256": attr.string(mandatory=True)
    }
)

Uygulama işlevindeki bir özelliğe erişmek için repository_ctx.attr.<attribute_name> kullanın:

def _impl(repository_ctx):
    url = repository_ctx.attr.url
    checksum = repository_ctx.attr.sha256

Tüm repository_rule'lar, örtülü olarak tanımlanmış özelliklere sahiptir (tıpkı kuralları) belirlemeye olanak tanır. İki örtülü özellik şunlardır: name (tıpkı derleme kurallarında olduğu gibi) ve repo_mapping. Bir depo kuralının adına şu kişiler kullanılarak erişilebilir: repository_ctx.name repo_mapping kelimesinin anlamı yerel depo kuralları local_repository ve new_local_repository.

_ ile başlayan özellik adları gizlidir ve kullanıcılar bu özellikleri ayarlayamaz.

Uygulama işlevi

Her depo kuralı için implementation işlevi gerekir. Belge, yükleme Aşamasında tam olarak yürütülür.

İşlevin tam olarak bir giriş parametresi (repository_ctx) vardır. İşlev, belirtilen parametreler göz önüne alındığında kuralın yeniden üretilebilir olduğunu belirtmek için None değerini veya söz konusu kural için bir dizi parametre içeren ve bu kuralı aynı deposu oluşturan yeniden üretilebilir bir kurala dönüştüren bir sözlük döndürür. Örneğin, Örneğin, Git deposunu izleyen bir kural için ilk başta bu değerde olan kayan bir dal yerine belirli bir taahhüt tanımlayıcısı belirtiliyor.

repository_ctx giriş parametresi, özellik değerlerine ve hermetik olmayan işlevlere (ikili dosya bulma, ikili dosya yürütme, depolama alanında dosya oluşturma veya İnternet'ten dosya indirme) erişmek için kullanılabilir. Daha fazla bağlam bilgisi için kitaplığa bakın. Örnek:

def _impl(repository_ctx):
  repository_ctx.symlink(repository_ctx.attr.path, "")

local_repository = repository_rule(
    implementation=_impl,
    ...)

Uygulama işlevi ne zaman yürütülür?

Deponun uygulama işlevi, Bazel için bir başka bir hedef her zaman başka bir hedef olduğunda veya komut satırında belirtip belirtmediğine bağlıdır. Ardından, uygulama işlevinin dosya sisteminde deposu oluşturması beklenir. Buna "getirme" adı verilir seçeceğim.

Normal hedeflerin aksine, deponun farklı olmasına neden olacak bir değişiklik olduğunda depoların yeniden getirilmesi gerekmez. Bu Çünkü Bazel'in değişiklikleri algılayamadığı veya her derleme için çok fazla ek yüke neden olur (örneğin, ağdan). Bu nedenle, depolar yalnızca aşağıdaki şeyler değişir:

WORKSPACE dosyası yükleyin.
Deponun uygulanmasını içeren Starlark kodu.
repository_ctx'nin getenv() yöntemine iletilen veya repository_rule öğesinin environ özelliğiyle tanımlanan herhangi bir ortam değişkeninin değeri. Bu ortam değişkenlerinin değerleri, --repo_env işaretiyle komut satırına sabitlenebilir.
read(), execute() ve benzeri öğelere iletilen dosyaların içeriği bir etiketle başvuruda bulunulan repository_ctx yöntemleri (örneğin, //mypkg:label.txt ancak mypkg/label.txt değil)
bazel sync yürütüldüğünde.

Depoların ne zaman ne zaman çalışacağını kontrol eden iki repository_rule parametresi vardır geri getirilir:

configure işareti ayarlanırsa depo yalnızca bazel sync parametresi kendisine iletildiğinde --configure üzerinde yeniden getirilir (özelliğin değeri kaldırılırsa bu komut yeniden getirme işlemine neden olmaz)
local işareti ayarlanırsa yukarıdaki durumlara ek olarak depo şu şekilde olur: yeniden getirilirse veya URL'leri etkileyen herhangi bir dosya, Bazel sunucusu depo değişikliklerinin bildirilmesi (ör. WORKSPACE dosyası veya dosya ya da web sayfası bir defa veya birden fazla web sitesi tarafından veya kodunun tanımlanması gerekir.

Bu durumlarda yerel olmayan depolar yeniden getirilmez. Bunun nedeni, bu depoların ağla iletişim kurduğu veya başka bir şekilde pahalı olduğu varsaymasıdır.

Uygulama işlevini yeniden başlatma

Uygulama işlevi, kod deposu işlenirken yeniden başlatılabilir istediği bir bağımlılık eksikse getirilir. Böyle bir durumda, uygulama işlevi durur, eksik bağımlılık bu işlev, bağımlılık çözüldükten sonra yeniden yürütülür. Gereksiz yeniden başlatmaları (ağ erişiminin tekrarlanması gerekebileceğinden pahalı olan) önlemek için, tüm etiket bağımsız değişkenlerinin mevcut bir dosyaya çözülmesi koşuluyla etiket bağımsız değişkenleri önceden getirilir. Sorun çözüldüğünde, yalnızca yürütme sırasında oluşturulan bir dizeden veya etiketten alınan yol işlevin yeniden başlatılması yeniden başlatmaya neden olabilir.

Harici depoların yeniden getirilmesini zorlama

Bazen harici bir depo, tanımında veya bağımlılıklarında herhangi bir değişiklik olmadan güncelliğini yitirebilir. Örneğin, kaynak getiren bir depo, üçüncü taraf deposunun belirli bir dalını takip edebilir ve bu dalda yeni taahhütler kullanılabilir. Bu durumda, bazel'dan tüm harici depoları koşulsuz olarak bazel sync çağırarak yeniden gönderin.

Ayrıca, bazı kurallar yerel makineyi inceler ve yerel makine yükseltilirse güncelliğini yitirebilir. Burada, Bazel'dan şunları yapmasını isteyebilirsiniz: yalnızca repository_rule tanımında configure özellik ayarlanmış, bazel sync --configure kullanın.

Örnekler

C++ otomatik yapılandırılmış araç zinciri: bir depo kuralı kullanır. Yerel C++ derleyicisi olan Bazel için C++ yapılandırma dosyalarını ortamı ve C++ derleyicisinin desteklediği işaretler.
Go depoları bağımlılık listesini tanımlamak için birkaç repository_rule kullanır gereken tüm bilgileri içerir.
rules_jvm_external, varsayılan olarak @maven adlı harici bir depo oluşturur. Bu depo, geçişli bağımlılık ağacındaki her Maven yapısını derleme hedefleri oluşturur.