Google Copybara: Depolar Arasında Kod Taşıma

 (github.com/google)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Copybara, Google içinde kullanılan bir araçtır; birden fazla depo arasında kaynak kodu dönüştürüp taşır ve confidential depolar ile public depoları senkronize etmek için kullanılır
  • Tek bir doğruluk kaynağını korumak için bir depo yetkili depo olarak seçilir; ancak katkılar herhangi bir depodan kabul edilebilir ve sürümler de herhangi bir depodan oluşturulabilir
  • Başlıca kullanım senaryosu tekrarlayan kod taşıma işlemleridir; confidential depodan public depoya belirli kodları aktarma ya da public depodaki değişiklikleri authoritative depoya alma akışlarını destekler
  • Copybara, durumu ayrı bir sunucuda değil hedef deponun commit message label alanlarında tutan stateless bir yapı kullanır; böylece birden fazla kullanıcı veya servis aynı yapılandırma ve depolarla aynı sonucu elde edebilir
  • Şu anda desteklenen depo türü Git'tir; Mercurial okuma desteği deneysel durumdadır ve genişletilebilir mimarisiyle özel origin ve destination bileşenleri eklenebilir

Copybara'nın çözdüğü sorun

  • Copybara, depolar arasında kaynak kodu taşıma ve dönüştürme için kullanılan bir araçtır
  • Kaynak kodunun birden fazla depoda bulunması gereken durumlar olabilir ve Copybara bu depolar arasında kodun dönüştürülmesini ve taşınmasını sağlar
  • Temel örneklerden biri, confidential depo ile public depo arasında senkronizasyonu koruyan projelerdir
  • En yaygın kullanım biçimi, kodu bir depodan diğerine tekrar tekrar taşımaktır
  • Ayrıca kodu yeni bir depoya tek seferlik taşımak için de kullanılabilir

Yetkili depo ve katkı akışı

  • Copybara, depolardan birinin authoritative repository olarak seçilmesini gerektirir
    • Bu, her zaman tek bir source of truth bulunmasını sağlamak içindir
  • Katkılar herhangi bir depodan yapılabilir
  • Sürümler de herhangi bir depodan oluşturulabilir
  • Yetkili olmayan depoda bir değişiklik olduğunda, Copybara bu değişikliği dönüştürüp yetkili depodaki uygun konuma taşıyabilir
    • Buna bir örnek, public depodaki bir contributor tarafından yapılan değişikliktir
    • Birleştirme çakışmaları, yetkili depoda eski değişiklikler işlenirken kullanılan yöntemle aynı şekilde ele alınır

Kullanım örnekleri

  • Copybara kullanım örnekleri şunları içerir
    • confidential depodaki kodun bir kısmını public depoya aktarmak
    • public depodaki kodu confidential depoya aktarmak
    • authoritative olmayan depodaki değişiklikleri authoritative depoya aktarmak
  • Örnek yapılandırma, core.workflow ile origin ve destination tanımlar
    • origin olarak git.github_origin ile https://github.com/google/copybara.git içindeki master kullanılır
    • destination olarak git.destination ile file:///tmp/foo kullanılır
    • destination_files, third_party/copybara/** yolunu hedefler ve README_INTERNAL.txt hariç tutulur
    • core.replace ve core.move, BUILD dosyası yollarını değiştirmek ve dizin taşımak için kullanılır
  • Çalıştırma örneği, bare Git deposu oluşturduktan sonra copybara copy.bara.sky komutunu çalıştırmaktır

Durum saklama yöntemi ve depo desteği

  • Copybara'nın temel özelliklerinden biri stateless yapısıdır
  • Daha doğru ifadeyle, durumu hedef depoda saklar
    • Saklama yeri, commit mesajlarındaki label alanlarıdır
  • Bu yöntem sayesinde birden fazla kullanıcı veya servis, aynı yapılandırma ve depo kombinasyonuyla aynı sonucu elde edebilir
  • Şu anda desteklenen depo türü Git'tir
  • Mercurial depolarından okuma mümkündür ancak hâlâ deneysel durumdadır
  • Genişletilebilir mimari sayesinde neredeyse her kullanım senaryosuna uygun özel origin ve destination bileşenleri eklenebilir
  • Diğer depo türleri için resmi destek ileride eklenecektir

Kurulum ve derleme

  • Başlamanın en kolay yolu, önceden derlenmiş ikili dosyalar içeren haftalık snapshot release sürümünü kullanmaktır
  • Yayınlanmamış bir sürümü kullanmak için HEAD üzerinden derleme yapılmalıdır
    • JDK 11 kurulumu gerekir
    • Bazel kurulumu gerekir
    • Kaynak kod git clone https://github.com/google/copybara.git ile klonlanır
    • bazel build //java/com/google/copybara ile derlenir
    • Çalıştırılabilir uberjar, bazel build //java/com/google/copybara:copybara_deploy.jar ile oluşturulur
    • Testler bazel test //... ile çalıştırılabilir
  • Bazı testler, Mercurial ve Quilt gibi temel araçların kurulu olmasını gerektirir
    • Pull Request ilgili modüllerle bağlantılı değilse bu testler atlanabilir
    • CI tüm testleri çalıştırır
  • Arch Linux üzerinde aur/copybara-git paketi kullanılabilir

Bazel'de önceden derlenmiş Copybara kullanımı

  • Haftalık snapshot release, Bazel içinde kullanılabilir
  • Copybara, class file version 65.0 ile sunulduğu için Java Runtime 21 veya üzeri ile çalıştırılmalıdır
    • Bunun için .bazelrc içine run --java_runtime_version=remotejdk_21 eklenmelidir
  • Release artifact, http_jar ile indirilir
    • WORKSPACE içinde load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_jar") kullanılır
    • MODULE.bazel içinde http_jar = use_repo_rule("@bazel_tools//tools/build_defs/repo:http.bzl", "http_jar") kullanılır
  • WORKSPACE veya MODULE.bazel içinde [version] yerine uygun değer yazılarak copybara_deploy.jar belirtilir
  • BUILD dosyasında java_binary tanımlanır ve main class olarak com.google.copybara.Main kullanılır
  • Çalıştırma örneği: bazel run //tools:copybara -- migrate copy.bara.sky

Harici Bazel deposu olarak kaynaktan derleme

  • Copybara bağımlılıkları için kolaylık sağlayan makrolar sunulur
  • WORKSPACE içine http_archive eklenir ve {{ sha256sum }} ile {{ commit }} değerleri doldurulur
  • Ardından şu makrolar yüklenip çağrılır
    • copybara_repositories()
    • copybara_maven_repositories()
    • copybara_go_repositories()
  • Workspace içinde bazel run @com_github_google_copybara//java/com/google/copybara -- <args...> ile derlenip çalıştırılabilir

Docker kullanımı

  • Copybara'yı Docker ile derleyip çalıştırma yöntemi şu anda deneyseldir
  • Derleme, docker build --rm -t copybara . ile yapılır
  • Çalıştırma, hedef kod kök dizininde docker run -it -v "$(pwd)":/usr/src/app copybara help biçiminde yapılır
  • Container çalıştırma argümanları yerine ortam değişkenleri kullanılabilir
    • COPYBARA_SUBCOMMAND=migrate: çalıştırılacak komutu değiştirir, varsayılan migrate
    • COPYBARA_CONFIG=copy.bara.sky: yapılandırma dosyası yolunu belirtir, varsayılan kök dizindeki copy.bara.sky
    • COPYBARA_WORKFLOW=default: çalıştırılacak workflow'u belirtir, varsayılan default
    • COPYBARA_SOURCEREF='': sourceref belirtir, varsayılan yoktur
    • COPYBARA_OPTIONS='': Copybara seçeneklerini belirtir, varsayılan yoktur
  • Git ayarları ve SSH kimlik bilgileri Docker container ile paylaşılabilir
    • Örnekte ~/.gitconfig, ~/.ssh ve SSH_AUTH_SOCK değerlerinin container içine mount edilmesi gösterilir

Belgeler ve iletişim

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News yorumları

  • Tam da oyun geliştirme stüdyomda kullanmak için yaptığım Perforce destek yamasını açık kaynak olarak yayımladıktan hemen sonra bu yazının çıkması ilginç oldu
    Copybara’nın başlıca kullanımının dahili Google kod dağıtımı olduğunu ve bu kodun Perforce ile ilişkili Piper’da bulunduğunu düşününce, Perforce desteğinin olmaması ve yalnızca Git desteğinin anlamlı ölçüde bulunması oldukça şaşırtıcıydı
    PR oluşturmadan önce Git geçmişine baktığımda çok sayıda Gerrit Change-ID işareti gördüm; bu yüzden bir yerlerde erişemediğim bir Gerrit kod inceleme sistemi olmasından ve PR’ımın upstream’e alınmamasından endişelendim
    Perforce için Gerrit/Rietveld olmaması da üzücü, ama her şeyi bekleyemeyiz
    https://github.com/google/copybara/pull/347

    • Gerrit/Rietveld’de Perforce desteği olmamasının nedenlerinden biri, Google’ın Piper’da tutulan kod değişiklikleri için bu araçları kullanmaması. Onun yerine Critique kullanıyor
      https://abseil.io/resources/swe-book/html/ch19.html
      https://read.engineerscodex.com/p/how-google-takes-the-pain-...
      Harici araçlar arasında Critique kadar iyi bir şey henüz bulamadım ve GitHub’ın zayıf PR inceleme aracının çoğu kişi tarafından kabul görmesi şaşırtıcı. Benzer seviyede bir araç bilen varsa duymak isterim
      Birkaç yıl önce Google’dan ayrılırken oldukça titiz araştırmıştım; https://codeapprove.com/ en yakın olanıydı ama onda da hâlâ çok eksik vardı
    • Piper, Perforce’un bir fork’u değil. Perforce ile API uyumlu, ancak tamamen farklı bir implementasyon
    • O depo PR kabul ediyor. Ancak içeride birleştirip sonra tekrar dışarı aktarma yöntemiyle
      Dahili monorepo’da yaşayan gVisor veya Bazel gibi açık kaynak projeler de küçük farklarla genelde benzer şekilde işletiliyor

  • Bu alandaki diğer ilginç araçlardan biri olarak Rust, commit senkronizasyonu için Josh adlı bir araç kullanıyor
    https://josh-project.dev
    Rust tarafında bir blog yazısı da var
    https://blog.rust-lang.org/inside-rust/2026/06/04/how-josh-h...
    Meta’da eskiden fbshipit adlı bir açık kaynak araç vardı, ancak herkese açık depoya göre artık kullanılmıyormuş
    https://github.com/facebookarchive/fbshipit
    Bu alanda başka araçlar da var mı?

  • Birden fazla depo biraz kod paylaşmak istiyor ama bunu bir kütüphaneye ayırıp referans vermek, sürüm yayını çıkarmak ve bağımlı depoları güncellemek zahmetine değmiyorsa, bu araç o durumda da kullanışlı mı?
    Örneğin ortak domain modelini içeren bir klasörü tek bir ana depodan diğer depolara basitçe senkronize etmek için kullanılıp kullanılamayacağını merak ediyorum
    Go tarzı “çok fazla bağımlılık tutmaktansa biraz kopyalamak daha iyidir” felsefesine yakın bir kullanım

    • Çoğunlukla harici açık kaynak projeleri dahili monorepo ile senkronize etmek için kullanılır. Politika gereği build çıktılarından ziyade kaynak kodu içe aktarmak istenir, ancak istisna alınabilir
      Bazı projeler monorepo’da geliştirilir ve Copybara ile dışarı aktarılır
      Bizim ekip bunu dahili olarak Starlark kural setlerinin sürüm yönetimi için de kullanıyor
    • İçeride bir monorepo varsa ve bunun bir kısmını dünyaya açık kaynak olarak yayımlamak istiyorsanız kullanılan araç bu. Yine de kodun monorepo içinde kalması gerektiğinden çözüm bu oluyor
      Herkese açık depoyu şirket içi özel deponun bağımlılığı yapmak geliştirme açısından epey baş ağrıtıcı. Bu tür bağımlılıklar ağaç gibi çoğalırsa gerçekten sorun olur
    • Copybara ile böyle işler de yapılabilir, ama bu şekilde kullanmak muhtemelen can sıkıcı ve sıkıcı olur. Bir kütüphaneyi ayırmaktan ya da birkaç dosyayı ayrı bir depoya itmekten daha zahmetli olabilir

  • Uzun süredir kullanıyorum; çoğunlukla büyük bir projenin içinde yapılan bir araç, bağımsız yayımlanacak kadar büyüdüğünde kullanıyorum
    Kodu dışa aktarıp geri içe almayı kapsayan çift yönlü dağıtımın tamamını yapacak kadar güçlü, ama bu iş çok zahmetli olduğu için tercih etmiyorum
    Ben genelde özgün depodan bir klasörü ayırıp geçmişini koruyan basit, tek seferlik bir dışa aktarma için kullanıyorum. Sonraki geliştirme yeni depoya taşınıyor
    Yeni proje yapısı tamamen farklı olsa bile Git blame çalıştığı için memnunum

    • Bu tek yönlü desen aslında Google içinde de kullanılan yöntem. Monorepo’dan GitHub’a dışa doğru senkronizasyon yapılıyor
      Çift yönlü kullanım dağınık hâle geliyor; çünkü yol yeniden eşleme, dosya hariç tutma, başlıkları kaldırma gibi dönüşümler tek yönde kolay olsa da her zaman temiz biçimde tersine çevrilemiyor
      İki taraf da ayrıştığında Copybara’nın temel çizgi takibi kafa karıştırıcı sonuçlar üretmeye başlıyor. Çünkü anlamsal olarak aynı commit bile dönüşümden sonra farklı SHA’lar oluşturuyor
      Bilinmesi gereken nokta, geçmişi “korumanın” gerçek bir taşıma değil, yeniden yazılmış commit’leri cherry-pick etme yöntemi olduğudur. Dosya içeriği ve yazar bilgisi aktarıldığı için Git blame çalışır, ancak SHA’lar yeniden oluşur
      Copybara özgün SHA’yı commit mesajı trailer’ı GitOrigin-RevId içine koyar; bu da sonradan depolar arasındaki commit’leri karşılaştırmak gerektiğinde işe yarar

  • 52 yılı aşan bir ilerleme yani :-)
    Temmuz 2026: Google copybara, iki üretim deposu arasında kod taşımayı mümkün kılıyor
    Mart 1974: IBM COPY, iki üretim partitioned data set arasında kod taşımayı mümkün kılıyordu. OS/MVT ve OS/VS2 TSO Data Utilities COPY, FORMAT, LIST, MERGE User's Guide and Reference https://www.computinghistory.org.uk/downloads/8987

  • Dagster’da, herkese açık deponun daha büyük bir dahili monorepo içinde yaşayabilmesi için hub-and-spoke modeli kurarken Copybara kullandık; çalıştı ama epey dolambaçlı işlem gerektirdi
    https://dagster.io/blog/monorepos-the-hub-and-spoke-model-an...

  • Hariç tutma ya da dönüştürme olmadan yalnızca depo senkronizasyonu gerekiyorsa, açıkçası kullanmazdım. Şimdilik uygun olabilir ama kaniko veya birçok Google ürünü/aracı gibi arşivlenir ya da sonlandırılırsa başınız derde girebilir
    GitLab’da GitLab’dan GitHub’a ya da başka Git sağlayıcılarına/sunucularına mirror etmek için çok basit bir yöntem var

    • Copybara’nın sonlandırılma olasılığının gerçekten düşük olduğunu düşünüyorum. Bildiğim kadarıyla google3 ile büyük ölçekli açık kaynak projelerinin bakım ve vendoring yöntemlerinde oldukça temel bir araç
    • Doğru, Copybara daha çok bir ya da iki yönde dönüşüm yapmak için kullanılan bir araç
      Örneğin harici bzl dosyalarını dahili Blaze BUILD uyumlu biçime dönüştürmek ya da harici import’lar ile dahili third_party tarzı import’lar arasında dönüşüm yapmak gibi
      Saf bir mirror için Copybara fazla ağır kaçar

  • Güzel. Ben de yaklaşık 5 yıl önce iç içe Git depoları ve script’lerle benzer bir şey yapıp özel ve herkese açık depoları birlikte yönetme amacına ulaşmıştım
    Shell script’im tabii ki Google ölçeğinde değildi

    • Benim de benzerdi. Başta bunun bir git subtree wrapper’ı olduğunu sanmıştım, ama bakınca çok daha fazla iş yaptığı anlaşılıyor
      Örneğin senkronizasyon sırasında commit yazarı e-postasını değiştirme özelliği de var