Google Copybara: リポジトリ間でのコードの変換と移動
Google Copybara: リポジトリ間でのコードの変換と移動
Google Copybara はリポジトリ間の同期されたコード移動を可能にします
Google Copybara は、リポジトリ間でソースコードを変換して移動するためのツールです。主に、機密(プライベート)リポジトリと公開リポジトリの間の同期を維持するために使用され、単一の信頼できる唯一の情報源(source of truth)を維持しながら、コードが複数の場所に存在できるようにします。
コア機能とユースケース
Copybara は、コンテンツに変換を適用しながら、リポジトリ間でコードを移動することを可能にします。主なユースケースは以下の通りです:
- プライベートから公開への同期: 機密リポジトリから特定のコードセクションを公開リポジトリへインポートする。
- 公開からプライベートへの同期: 公開リポジトリからコードを機密リポジトリへインポートする。
- コントリビューション管理: 非権威的なリポジトリ(公開コントリビューターの PR など)からの変更を、権威的なリポジトリへ移動し、内部構造に合わせてコードを変換する。
- 一回限りの移行: 履歴を保持しながら、コードを新しいリポジトリへ一度だけ移動する。
技術アーキテクチャと状態管理
Copybara はステートレスに設計されています。何が移動されたかを記録する外部データベースを維持する代わりに、コミットメッセージ内のラベルを使用して、送信先リポジトリ内に状態を保存します。このアーキテクチャにより、複数のユーザーや自動化されたサービスが、同じリポジトリに対して同じ設定を実行し、一貫した結果を得ることができます。
現在、Copybara は Git リポジトリを公式にサポートしており、Mercurial の実験的なサポートも提供しています。その拡張可能なアーキテクチャは、さまざまなユースケースに合わせて、独自の origin や destination を追加できるように設計されています。
設定と実装
Copybara は、ワークフローを定義するために設定言語(通常は .sky ファイル)を使用します。ワークフローは、origin、destination、移動するファイル(glob を使用)、および適用される変換(transformations)を定義します。
ワークフローのロジック例:
core.workflow(
name = "default",
origin = git.github_origin(
url = "https://github.com/google/copybara.git",
ref = "master",
),
destination = git.destination(
url = "file:///tmp/foo",
),
destination_files = glob(["third_party/copybara/**"], exclude = ["README_INTERNAL.txt"]),
transformations = [
core.replace(
before = "//third_party/bazel/bashunit",
after = "//another/path:bashunit",
paths = glob(["**/BUILD"])),
core.move("", "third_party/copybara")
],
)
インストールとデプロイメントのオプション
Copybara は、環境に応じていくつかの方法でデプロイできます:
- ビルド済みバイナリ: GitHub 上で毎週のスナップショットリリースが提供されており、Java Runtime 21 以上が必要です。
- Bazel ビルド: JDK 11 と Bazel を使用してソースからコンパイルできます。また、提供されている便利なマクロを使用して、外部 Bazel リポジトリとして統合することも可能です。
- Docker: 実験的な Docker イメージが提供されており、コンテナ経由で Copybara を実行できます。この方法では、実行を制御するために環境変数(例:
COPYBARA_CONFIG,COPYBARA_WORKFLOW)を使用でき、リポジトリへのアクセス用に.gitconfigや SSH 認証情報をマウントすることが可能です。
コミュニティの洞察と代替案
ユーザーや開発者は、他のバージョン管理戦略と比較した Copybara の有用性について、いくつかの視点を提供しています:
- モノレポの生産性: 一部のユーザーは、内部モノレポの公開向けコンポーネントを管理するために Copybara を使用することで、大幅な生産性が向上したと報告しています。
- 履歴の保持: フォルダを新しいリポジトリへ移動しつつ Git blame 履歴を保持する「fire and forget」型のエクスポートにおいて、効果的なツールとして注目されています。
- 代替案: GitLab の組み蔵のミラーリング機能、Git submodules、または Git subtrees の使用が議論の対象となっています。その他の専門的なツールとして、Josh(Rust プロジェクトで使用)や、現在はアーカイブされている Meta の fbshipit が挙げられています。
- トレードオフ: 一部のコントリビューターは、変換や除外設定なしの単純なリポジトリ・ミラーリングを行う場合、より単純な組み込みのベンダーツールの方が信頼性が高い可能性があると警告しています。
"If the only need you need is sync repos without exclusions or transformations I wouldn't bother... Gitlab has really simple way to mirror from Gitlab to Github or other git vendors/servers"
"I've seen many teams gain significant productivity when collaborating in a monorepo with public bits."
"summary":