複数のリポジトリにまたがる複数のコンポーネントを 1 つのプロジェクトに管理する社内ツールがあります。Google のレポ ツール ( https://code.google.com/p/git-repo/ ) または gitslave ( http://gitslave.sourceforge.net/ )に性質が似ています。私たちのプロジェクトは、単一の git リポジトリではありません。
依存関係は、常に最初にチェックアウトされる「メタ」リポジトリで定義され、その後で依存関係がチェックアウトされます。
私は Jenkins を調査しており、ツールを使用して複数のリポジトリを持つ作業領域をチェックアウトする方法を見つけようとしています。
誰かが前にこのようなことをしたことがありますか? 私はジェンキンスのドキュメントに少し戸惑い、どこから始めればよいのかよくわかりません。
ツールを使用したいので、最初のビルドステップで (または Maven ビルドのビルド前ステップとして) 実行できます。@Electrawn が既に述べたように、リビジョン番号が失われます。ただし、これにも回避策があります。ただし、リビジョン番号を含むプロパティ ファイルを作成できる場合は、EnvInject プラグインを使用してプロパティ ファイルを読み込むことができます。その時点から、ビルド ジョブのプロパティにアクセスできるようになります。また、変更を自動的にチェックする Jenkins の機能も失われます。自家製のツールがこの機能をサポートしている場合は、変更のみをチェックし、変更が見つかったときにビルド ジョブをトリガーする 2 番目のジョブを作成できます。
これは考えられる回避策の 1 つにすぎません。少しの創造性で、さまざまな解決策を考え出すことができます。
もちろん、最善の方法は、独自の Jenkins プラグインを作成することです。大部分は既に (独自のツールを作成して) 完了しているため、Jenkins API を実装するだけで済みます。... または、プロジェクト構造に合わせて現在の git プラグインを更新する方が速いかもしれません。
Subversion (および jenkins subversion プラグイン) では、SVN:Externals を介して簡単にこれを行うことができます。個人的な意見は置いといて…
git には簡単な外部機能が組み込まれていないため、必要なリポジトリのさまざまな部分をチェックアウトするだけのシェル呼び出しの複数のビルド前ステップを追加することをお勧めします。他の SCM プラグインのように自動で REVISION 番号を取得することはできません。
メイン プロジェクトをチェックアウトするための SCM プラグイン
ビルド タスク 1 (Linux を想定):
git clone REPO %{WORKSPACE}/source/project2
ビルド タスク 2:
git clone REPO %{WORKSPACE}/source/project3
次に、最初のコメント投稿者ごとに、ジョブのモジュール化とアーティファクトのチェーンへの押し込みを調査できますが、最初に 1 つの大規模なジョブでプロジェクトを構築することができます。