Google Copybara: रिपॉजिटरीज़ के बीच कोड मूव करना

 (github.com/google)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Copybara Google के भीतर इस्तेमाल होने वाला एक टूल है, जो कई repositories के बीच source code को transform और move करके confidential repository और public repository को sync रखने जैसे मामलों में उपयोग होता है
  • एक repository को authoritative repository के रूप में चुनकर single source of truth बनाए रखा जाता है, लेकिन contribution किसी भी repository से लिया जा सकता है और release भी किसी भी repository से बनाया जा सकता है
  • इसका मुख्य use case बार-बार code move करना है, और यह confidential repository से public repository में कुछ code लाने या public repository के बदलाव authoritative repository में लाने वाले flow को support करता है
  • Copybara state को अलग server में नहीं, बल्कि target repository के commit message labels में store करने वाले stateless तरीके का उपयोग करता है, इसलिए कई user या service एक ही config और repository पर समान result प्राप्त कर सकते हैं
  • अभी समर्थित repository type Git है, जबकि Mercurial read experimental feature है, और इसकी extensible संरचना के कारण custom origin और destination जोड़े जा सकते हैं

Copybara किस समस्या को हल करता है

  • Copybara repositories के बीच source code को move और transform करने का एक टूल है
  • कई बार source code को कई repositories में मौजूद रहना पड़ता है, और Copybara ऐसे repositories के बीच code को transform और move करने देता है
  • इसका प्रमुख उदाहरण confidential repository और public repository को sync करके बनाए रखने वाले project हैं
  • इसका सबसे आम उपयोग एक repository से दूसरी repository में code को बार-बार ले जाना है
  • इसे code को किसी नई repository में सिर्फ एक बार migrate करने के लिए भी इस्तेमाल किया जा सकता है

Authoritative repository और contribution flow

  • Copybara में repositories में से एक को authoritative repository के रूप में चुनना जरूरी है
    • यह सुनिश्चित करने के लिए कि हमेशा एक source of truth मौजूद रहे
  • contribution किसी भी repository में किया जा सकता है
  • release भी किसी भी repository से बनाया जा सकता है
  • अगर non-authoritative repository में बदलाव होता है, तो Copybara उस बदलाव को transform करके authoritative repository के सही स्थान पर ले जा सकता है
    • उदाहरण के तौर पर, public repository के contributor द्वारा किया गया बदलाव
    • merge conflict को authoritative repository के भीतर पुराने बदलावों को संभालने के समान तरीके से deal किया जाता है

उपयोग के उदाहरण

  • Copybara के उपयोग के उदाहरणों में शामिल हैं
    • confidential repository के code का कुछ हिस्सा public repository में लाना
    • public repository के code को confidential repository में लाना
    • non-authoritative repository के बदलाव authoritative repository में लाना
  • example config core.workflow के जरिए origin और destination को define करता है
    • origin git.github_origin के साथ https://github.com/google/copybara.git की master branch का उपयोग करता है
    • destination git.destination के साथ file:///tmp/foo का उपयोग करता है
    • destination_files में third_party/copybara/** को target किया जाता है और README_INTERNAL.txt को exclude किया जाता है
    • core.replace और core.move के जरिए BUILD file path replace और directory move किया जाता है
  • execution example में bare Git repository बनाने के बाद copybara copy.bara.sky चलाया जाता है

State storage का तरीका और repository support

  • Copybara की प्रमुख विशेषताओं में से एक इसकी stateless संरचना है
  • अधिक सटीक रूप से कहें तो यह state को target repository में store करता है
    • storage location commit message का label होता है
  • इस तरीके से कई user या service एक ही config और repository combination के साथ समान result प्राप्त कर सकते हैं
  • वर्तमान में समर्थित repository type Git है
  • Mercurial repository से read करना संभव है, लेकिन अभी experimental है
  • extensible architecture के जरिए लगभग हर use case के लिए bespoke origin और destination जोड़े जा सकते हैं
  • अन्य repository types के लिए official support भविष्य में जोड़ा जाएगा

Installation और build

  • शुरू करने का सबसे आसान तरीका prebuilt binaries वाली साप्ताहिक snapshot release का उपयोग करना है
    • releases अपने-आप बनाई जाती हैं
    • manual testing, version compatibility, या correctness की कोई guarantee नहीं है
    • release को https://github.com/google/copybara/releases से चुना जा सकता है
  • unreleased version इस्तेमाल करने के लिए HEAD से build करना होगा
    • JDK 11 install होना चाहिए
    • Bazel install होना चाहिए
    • git clone https://github.com/google/copybara.git से source clone करें
    • bazel build //java/com/google/copybara से build करें
    • executable uberjar bazel build //java/com/google/copybara:copybara_deploy.jar से बनता है
    • test bazel test //... से चलाए जा सकते हैं
  • कुछ tests के लिए Mercurial, Quilt जैसे underlying tools install होने चाहिए
    • अगर Pull Request उन modules से संबंधित नहीं है, तो वे tests skip किए जा सकते हैं
    • CI सभी tests चलाता है
  • Arch Linux पर aur/copybara-git package का उपयोग किया जा सकता है

Bazel में prebuilt Copybara का उपयोग

  • साप्ताहिक snapshot release को Bazel में इस्तेमाल किया जा सकता है
  • Copybara class file version 65.0 के साथ दिया जाता है, इसलिए इसे चलाने के लिए Java Runtime 21 या उससे ऊपर चाहिए
    • .bazelrc में run --java_runtime_version=remotejdk_21 जोड़ना होगा
  • http_jar के जरिए release artifact डाउनलोड किया जाता है
    • WORKSPACE में load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_jar") का उपयोग करें
    • MODULE.bazel में http_jar = use_repo_rule("@bazel_tools//tools/build_defs/repo:http.bzl", "http_jar") का उपयोग करें
  • WORKSPACE या MODULE.bazel में [version] की जगह भरकर copybara_deploy.jar को specify करें
  • BUILD file में java_binary declare करके com.google.copybara.Main को main class के रूप में उपयोग किया जाता है
  • execution example है bazel run //tools:copybara -- migrate copy.bara.sky

External Bazel repository के रूप में source build

  • Copybara dependencies के लिए convenience macros दिए जाते हैं
  • WORKSPACE में http_archive जोड़ें और {{ sha256sum }} तथा {{ commit }} values भरें
  • इसके बाद नीचे दिए गए macros को load और call करें
    • copybara_repositories()
    • copybara_maven_repositories()
    • copybara_go_repositories()
  • workspace के भीतर bazel run @com_github_google_copybara//java/com/google/copybara -- <args...> के जरिए build और run किया जा सकता है

Docker का उपयोग

  • Docker के साथ Copybara को build और run करने का तरीका फिलहाल experimental है
  • build docker build --rm -t copybara . से किया जाता है
  • run target code root में docker run -it -v "$(pwd)":/usr/src/app copybara help के रूप में किया जाता है
  • container run arguments की जगह environment variables का उपयोग किया जा सकता है
    • COPYBARA_SUBCOMMAND=migrate: run command बदलता है, default migrate है
    • COPYBARA_CONFIG=copy.bara.sky: config file path specify करता है, default root की copy.bara.sky है
    • COPYBARA_WORKFLOW=default: चलाए जाने वाले workflow को specify करता है, default default है
    • COPYBARA_SOURCEREF='': sourceref specify करता है, default नहीं है
    • COPYBARA_OPTIONS='': Copybara options specify करता है, default नहीं है
  • Git config और SSH credentials को Docker container के साथ share किया जा सकता है
    • उदाहरण के तौर पर ~/.gitconfig, ~/.ssh, SSH_AUTH_SOCK को container में mount किया जा सकता है

Documentation और संपर्क

  • documentation अभी भी तैयार की जा रही है
  • उपलब्ध सामग्री में शामिल हैं
  • सवाल mailing list पर पूछे जा सकते हैं
  • Bazel test errors को log file cat किए बिना देखने के लिए ~/.bazelrc में test --test_output=streamed जोड़ा जा सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की रायें

  • मज़ेदार लगा कि यह पोस्ट ठीक तब आई जब मैंने गेम डेवलपमेंट स्टूडियो में इस्तेमाल के लिए बनाया अपना Perforce support patch open source किया था
    Copybara का मुख्य इस्तेमाल internal Google code distribution है, और वह code Piper में है जो Perforce से जुड़ा है—यह देखते हुए Perforce support न होना और सिर्फ Git support का ही ढंग से होना काफ़ी चौंकाने वाला था
    PR बनाने से पहले जब Git history देखी तो Gerrit Change-ID के बहुत निशान दिखे, इसलिए थोड़ा डर भी लगा कि कहीं कोई ऐसा Gerrit code review system है जिस तक मेरी access नहीं है और मेरा PR upstream न हो पाए
    Perforce के लिए Gerrit/Rietveld न होना भी अफ़सोस की बात है, लेकिन सब कुछ तो नहीं मिल सकता
    https://github.com/google/copybara/pull/347

    • Gerrit/Rietveld में Perforce support न होने की एक वजह यह है कि Google Piper में stored code changes के लिए उन tools का इस्तेमाल नहीं करता। इसके बजाय वह Critique इस्तेमाल करता है
      https://abseil.io/resources/swe-book/html/ch19.html
      https://read.engineerscodex.com/p/how-google-takes-the-pain-...
      बाहरी tools में Critique जितना अच्छा कुछ अभी तक नहीं मिला, और यह हैरान करने वाली बात है कि GitHub के कमजोर PR review tools को ज़्यादातर लोग स्वीकार कर लेते हैं। अगर किसी को इसी स्तर का कोई tool पता हो तो सुनना चाहूंगा
      कुछ साल पहले Google छोड़ते समय मैंने काफ़ी बारीकी से खोजा था, और https://codeapprove.com/ सबसे करीब था, लेकिन उसमें भी अभी बहुत कुछ missing था
    • Piper, Perforce का fork नहीं है। यह Perforce के साथ API-compatible है, लेकिन implementation पूरी तरह अलग है
    • वह repository PR स्वीकार करती है। बस तरीका यह है कि पहले internal रूप से merge किया जाता है, फिर वापस बाहर export किया जाता है
      internal monorepo में रहने वाले gVisor या Bazel जैसे open source projects भी थोड़े-बहुत फर्क के साथ आम तौर पर इसी तरह चलते हैं

  • इस क्षेत्र का एक और दिलचस्प tool Rust में है: commits sync करने के लिए वह Josh नाम का tool इस्तेमाल करता है
    https://josh-project.dev
    Rust की तरफ़ से एक blog post भी है
    https://blog.rust-lang.org/inside-rust/2026/06/04/how-josh-h...
    Meta के पास पहले fbshipit नाम का एक open source tool था, लेकिन public repository के मुताबिक अब वे इसका इस्तेमाल नहीं करते
    https://github.com/facebookarchive/fbshipit
    क्या इस space में और भी tools हैं?

  • क्या यह तब भी convenient है जब कई repositories थोड़ा-सा code share करना चाहती हों, लेकिन उसे library में अलग करने, references जोड़ने, version releases publish करने और dependent repositories update करने की मेहनत worth it न हो?
    उदाहरण के लिए, क्या इसे ऐसे इस्तेमाल किया जा सकता है कि common domain models वाला एक folder किसी एक main repository से दूसरी repositories में बस sync हो जाए?
    यह Go वाली philosophy के करीब use case है: “बहुत सारी dependencies रखने से थोड़ा copy करना बेहतर है”

    • मुख्य रूप से external open source projects को internal monorepo के साथ sync करने में इस्तेमाल होता है। Policy source code import करने की मांग करती है, build artifacts से ज़्यादा, हालांकि exceptions मिल सकते हैं
      कुछ projects monorepo में develop होते हैं और Copybara से बाहर export किए जाते हैं
      हमारी team internally Starlark ruleset की version management के लिए भी इसका इस्तेमाल करती है
    • यह उस समय के लिए tool है जब आपके पास internal monorepo हो और आप उसका कुछ हिस्सा दुनिया के लिए open source करना चाहते हों। फिर भी code को monorepo के अंदर ही रहना है, इसलिए यह solution बनता है
      public repository को company की private repository की dependency बनाना development के लिहाज से काफी सिरदर्द है। ऐसी dependencies अगर tree की तरह बढ़ने लगें तो सच में headache बन जाती हैं
    • Copybara से ऐसा काम भी किया जा सकता है, लेकिन उसे इस तरह इस्तेमाल करने पर यह झुंझलाहट भरा और उबाऊ होने की संभावना है। Library अलग करने या कुछ files को अलग repository में डालने की समस्या से भी ज्यादा annoying हो सकता है

  • इसे काफी समय से इस्तेमाल कर रहा हूँ, और आम तौर पर तब इस्तेमाल करता हूँ जब किसी बड़े प्रोजेक्ट के अंदर बनाया गया कोई tool इतना बड़ा हो जाए कि उसे स्वतंत्र रूप से release किया जा सके
    यह code को बाहर भेजने और फिर वापस लाने वाली पूरी two-way deployment करने जितना powerful है, लेकिन वह सब इतना झंझट भरा है कि मैं उससे बचता हूँ
    मैं आम तौर पर मूल repository से एक folder अलग करने, लेकिन history बचाए रखने वाले सरल one-off export के लिए इसे इस्तेमाल करता हूँ। उसके बाद development नए repository में चला जाता है
    नया project structure पूरी तरह अलग होने पर भी Git blame काम करता है, इसलिए मैं संतुष्ट हूँ

    • वह one-way pattern असल में Google के अंदर भी इस्तेमाल होने वाला तरीका है। monorepo से GitHub की ओर बाहर sync किया जाता है
      two-way messy हो जाता है, क्योंकि path remapping, file exclusion, header removal जैसे transformations एक दिशा में आसान होते हैं, लेकिन हमेशा साफ़ तौर पर reverse-transform नहीं किए जा सकते
      जब दोनों तरफ diverge हो जाते हैं, तो Copybara की baseline tracking उलझे हुए नतीजे देने लगती है। क्योंकि semantic रूप से वही commit भी transformation के बाद अलग-अलग SHA बनाता है
      जानने लायक बात यह है कि history “preservation” असली transplant नहीं है, बल्कि rewritten commits को cherry-pick करने का तरीका है। file content और author info आ जाती है, इसलिए Git blame काम करता है, लेकिन SHA नए बनते हैं
      Copybara original SHA को commit message trailer GitOrigin-RevId में रख देता है, इसलिए बाद में repositories के बीच commits मिलाने हों तो यह उपयोगी होता है

  • 52 साल से ज्यादा की प्रगति है :-)
    जुलाई 2026: Google copybara दो production repositories के बीच code ले जाने देता है
    मार्च 1974: IBM COPY दो production partitioned data sets के बीच code ले जाने देता था। OS/MVT और OS/VS2 TSO Data Utilities COPY, FORMAT, LIST, MERGE User's Guide and Reference https://www.computinghistory.org.uk/downloads/8987

  • Dagster में public repository को बड़े internal monorepo के अंदर रहने देने के लिए hub-spoke model बनाने में Copybara का इस्तेमाल किया, और यह चला भी, लेकिन काफी सारे workaround करने पड़े
    https://dagster.io/blog/monorepos-the-hub-and-spoke-model-an...

  • अगर सिर्फ repository sync चाहिए, बिना exclusions या transformations के, तो शायद मैं इसे इस्तेमाल नहीं करूँगा। अभी के लिए ठीक हो सकता है, लेकिन अगर kaniko या कई Google products/tools की तरह archive या बंद हो गया तो मुश्किल हो सकती है
    GitLab में GitLab से GitHub या दूसरे Git providers/servers पर mirroring करने का एक बहुत सरल तरीका है

    • मुझे लगता है Copybara के बंद होने की संभावना सच में बहुत कम है। मेरी जानकारी में google3 और बड़े open source projects को maintain और vendor करने के तरीके में यह काफी core tool है
    • सही, Copybara एक या दोनों दिशाओं में transformations करने के लिए इस्तेमाल होने वाला tool ज्यादा है
      उदाहरण के लिए external bzl को internal Blaze BUILD compatible रूप में बदलना, या external imports और internal third_party style imports के बीच बदलना जैसे काम
      pure mirror के लिए Copybara जरूरत से ज्यादा heavy है

  • अच्छा है। मैंने भी करीब 5 साल पहले nested Git repositories और scripts से कुछ similar बनाया था, जिससे private और public repositories को साथ संभालने का उद्देश्य पूरा हुआ
    मेरी shell scripts जाहिर तौर पर Google scale की नहीं थीं

    • मेरे साथ भी कुछ ऐसा ही था। शुरू में लगा था कि यह git subtree wrapper होगा, लेकिन देखने पर लगता है यह उससे कहीं ज्यादा काम करता है
      उदाहरण के लिए sync के दौरान commit author email बदलने की सुविधा भी है