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 depolama alanı kuralı, kendi BUILD dosyaları ve yapılarıyla kendi çalışma alanını oluşturur. Bunlar, üçüncü taraf kitaplıklara (Maven paketlenmiş kitaplıklar gibi) bağlı olmanın yanı sıra Bazel'in çalıştığı ana makineye özel BUILD dosyaları oluşturmak için de kullanılabilir.

Depo kuralı oluşturma

Yeni bir depolama alanı kuralı oluşturmak ve bunu bir genel değişkende depolamak için .bzl dosyasında repository_rule işlevini kullanın.

Özel depo kuralı, yerel depo kuralı gibi kullanılabilir. Zorunlu bir name özelliğine sahiptir ve derleme dosyalarında bulunan her hedef @<name>//package:target olarak ifade edilebilir. Burada <name>, name özelliğinin değeridir.

Kural, açıkça derlediğinizde veya derlemenin bir bağımlılığı olduğunda yüklenir. Bu durumda Bazel, implementation işlevini yürütür. Bu işlev, deposu, içeriğini ve BUILD dosyalarını nasıl oluşturacağınızı açıklar.

Özellikler

Özellikler, attrs kural bağımsız değişkenine dikt 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 dize olarak tanımlayan örnek:

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 öğelerinin, dolaylı olarak tanımlanmış özellikleri vardır (tıpkı derleme kuralları gibi). İki gizli özellik name (derleme kurallarında olduğu gibi) ve repo_mapping'dır. Bir depo kuralının adına repository_ctx.name ile erişilebilir. repo_mapping, yerel depo kuralları local_repository ve new_local_repository ile aynı anlama gelir.

Özellik adı _ ile başlıyorsa özeldir ve kullanıcılar bunu ayarlayamaz.

Uygulama işlevi

Her depo kuralı için bir implementation işlevi gerekir. Kuralın gerçek mantığını içerir ve yalnızca Yükleme Aşamasında yürütülür.

İşlevin tam olarak bir giriş parametresi (repository_ctx) vardır. İşlev, belirtilen parametreler verildiğinde kuralın yeniden üretilebilir olduğunu belirtmek için None değerini veya söz konusu kural için aynı deposu oluşturan, kuralın yeniden üretilebilir hale gelmesini sağlayacak bir parametre grubu içeren bir sözlük döndürür. Örneğin, bir git deposunu izleyen bir kural için bu, başlangıçta belirtilen değişken dal yerine belirli bir taahhüt tanımlayıcısı döndürülmesi anlamına gelir.

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?

Bir deposunun uygulama işlevi, Bazel'in söz konusu depodan bir hedefe ihtiyacı olduğunda (ör. başka bir depodaki başka bir hedef ona bağlı olduğunda veya komut satırında söz konusu depodan bahsedildiğinde) yürütülür. Ardından, uygulama işlevinin depoyu dosya sisteminde oluşturması beklenir. Buna depoyu "getirme" denir.

Normal hedeflerin aksine depolar, deponun farklı olmasına neden olacak bir değişiklik olduğunda mutlaka yeniden getirilmez. Bunun nedeni, Bazel'in değişiklikleri algılayamadığı veya her derlemede çok fazla ek yüke neden olduğu şeyler (ör. ağdan getirilen öğeler) olmasıdır. Bu nedenle, depolar yalnızca aşağıdakilerden biri değişirse yeniden getirilir:

  • WORKSPACE dosyasındaki depo bildirimine iletilen parametreler.
  • 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şareti kullanılarak komut satırına kabloyla bağlanabilir.
  • Bir etiketle (ör. mypkg/label.txt değil //mypkg:label.txt) atıfta bulunulan repository_ctx'nin read(), execute() ve benzer yöntemlerine iletilen herhangi bir dosyanın içeriği
  • bazel sync yürütüldüğünde.

Depoların ne zaman yeniden getirileceğini kontrol eden iki repository_rule parametresi vardır:

  • 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 ayarlanmışsa, yukarıdaki durumlara ek olarak Bazel sunucusu yeniden başlatıldığında veya deponun tanımını etkileyen herhangi bir dosya (ör. WORKSPACE dosyası veya yüklediği bir dosya) değiştiğinde de depo yeniden getirilir. Bu değişiklikler, deponun tanımında veya kodunda bir değişikliğe neden olup olmadığına bakılmaksızın yapılır.

    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

İstediği bir bağımlılık eksikse, uygulama işlevi bir depo getirilirken yeniden başlatılabilir. Bu durumda, uygulama işlevinin yürütmesi durdurulur, eksik bağımlılık çözülür ve bağımlılık çözüldükten sonra işlev yeniden yürütülür. Gereksiz yeniden başlatmalardan (ağ erişiminin tekrarlanması gerekebileceğinden pahalı olan) kaçınmak 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. Yalnızca işlevin yürütülmesi sırasında oluşturulan bir dize veya etiketten bir yolun çözülmesinin yine de yeniden başlatmaya neden olabileceğini unutmayın.

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 sync çağrısını yaparak bazel'den tüm harici depoları koşulsuz olarak yeniden getirmesini isteyebilirsiniz.

Ayrıca, bazı kurallar yerel makineyi inceler ve yerel makine yükseltilirse güncelliğini yitirebilir. Burada bazel'den yalnızca repository_rule tanımının configure özelliğinin ayarlandığı harici depoları yeniden getirmesini isteyebilirsiniz. bazel sync --configure değerini kullanın.

Örnekler

  • C++ otomatik olarak yapılandırılmış araç zinciri: Yerel C++ derleyicisi, ortam ve C++ derleyicinin desteklediği işaretleri arayarak Bazel için C++ yapılandırma dosyalarını otomatik olarak oluşturmak üzere bir depo kuralı kullanır.

  • Go depoları, Go kurallarını kullanmak için gereken bağımlılıkların listesini tanımlamak üzere çeşitli repository_rule öğelerini kullanır.

  • 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.