16

現在の Buildbot セットアップを置き換えるために Hudson を試しています。gitプラグインをインストールしました。現在のセットアップは次のようなものです。

ssh://server:/repo/test_framework.git
ssh://server:/repo/project_a.git

ここで、ビルドするためproject_aに、複数の git リポジトリ (上記のもの) を持つ新しいジョブを追加しました。その階層が必要なため、ハドソンにリポジトリを の下の別のディレクトリに複製してもらいたいと思い$WORKSPACEました。しかし、ハドソンは代わりにtest_frameworkすべてをマージするようです. $WORKSPACEコンソール ログから:

warning: no common commits
...
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 96d2b3c27595de243702414c4358366923696d78
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 5bb011b3fa288afd5e4392640b32b8bcc982103e
[workspace] $ git merge-base ce14a4579e87971659e5e0469136713847055a29 aa6ade81669883909ba5f5459a205df1bd0df3c0

プロジェクトのセットアップに合わせて Hudson でこれを構成できますか? すべてのプロジェクトを git サブモジュールなどとしてローカルのダミー git リポジトリを作成する必要がありますか?

4

5 に答える 5

6

「他のプロジェクトをビルドする」ソリューションの問題は、test_framework に変更がある場合、project_a のビルドがトリガーされないことです。代わりに、git プラグインを放棄し、次のように「シェルの実行」ビルド ステップを設定することをお勧めします。

rm -rf ${WORKSPACE}/*

git clone ssh://server:/repo/test_framework.git ${WORKSPACE}/test_framework
cd ${WORKSPACE}/test_framework
git fetch -t ssh://user@server:/repo/test_framework.git +refs/heads/*:refs/remotes/origin/*
git ls-tree HEAD

git clone ssh://server:/repo/project_a.git ${WORKSPACE}/project_a
cd ${WORKSPACE}/project_a
git fetch -t ssh://user@server:/repo/project_a.git +refs/heads/*:refs/remotes/origin/*
git ls-tree HEAD

次に、フック ファイル「server:/repo/test_framework.git/hooks/post-receive」および「server:/repo/project_a.git/hooks/post-receive」を次の内容で作成します。

#!/bin/sh
curl http://hudson/job/job_name/build

これで、変更がいずれかのリポジトリにプッシュされるたびに、フックは Hudson の API を使用してビルドをトリガーします。

于 2010-07-09T18:41:05.357 に答える
6

この質問は非常に古いことを認識していますが、同じ問題に遭遇し、このページを使用して、非常にうまく機能しているように見える独自のソリューションを具体化しました (少し複雑ですが)。このソリューションの功績のほとんどは Clinton に帰すべきです (私がわざわざこの回答を提出したのは、彼の回答が同じベース ディレクトリにある必要がある複数のリポジトリに対応していないように見えるからです)。

2 つのリポジトリ (A と B) があるとします。

手順:

1) 2 つのプロジェクトを作成して、リモート リポジトリ A と B からコードをプルします。必要なビルド ステップをいずれかのリポジトリに配置します。

2) ソース管理の管理なしで 3 番目のディレクトリを作成します。このプロジェクトにビルド ステップを追加して、次のようなシェル コマンドを実行します。

ln -s /var/lib/jenkins/jobs/A/workspace A
ln -s /var/lib/jenkins/jobs/B/workspace B

(あなたのパスは同じではないかもしれません。自分で調べてください!)

これで、ディレクトリ内の姉妹である A と B に依存する他のビルド ステップを追加できます。イェーイシンボリックリンク！

3) 3 つのタスクを連鎖させます。プル タスクの順序は重要かもしれませんし、重要でないかもしれません (私よりよく知っているでしょう) が、ソース管理のないタスクはチェーンの最後のリンクであるべきです。

于 2011-03-21T03:53:31.807 に答える
6

Hudson 内では、複数のジョブを連鎖させることができます。test_framework 用と project_a 用に別の Hudson ジョブを作成してみてください。Hudson はジョブごとに $WORKSPACE に個別のディレクトリを作成するため、$WORKSPACE の下に 2 つの異なるディレクトリが作成されます。

チェーンのセットアップ

project_a のジョブ構成で、Post-build actions まで下にスクロールし、Build other projects... をチェックして、ビルドするプロジェクトとして test_framework を入力します。

test_framework のジョブ構成で、Poll SCM がオフになっていること、および Build after other projects が project_a に設定されていることを確認します。

使い方

これで構成したのは、project_a が SCM をポーリングして変更を探し、変更が見つかった場合に git からプルすることです。ビルド ステップを実行し (存在する場合)、完了時に test_framework ジョブをトリガーして、git から変更をプルし (存在する場合)、そのビルド ステップを実行します。

于 2009-11-29T22:41:52.783 に答える
1

あなたが説明している問題は、Jenkinsバグトラッカーにバグとしてすでに提出されています：https ：//issues.jenkins-ci.org/browse/JENKINS-8082

拡張プロジェクトジョブ構成の「カスタムワークスペース」オプションを使用して、ジョブのリポジトリを別のジョブのサブディレクトリにチェックアウトします。

その他のジョブは、すべてのサブモジュールを含むメインディレクトリをチェックアウトします。

var/lib/jenkins/jobs/
  + main_job
    + workspace (main git checkout with submodules)
      + modules
        + mod1
        + mod2
  + mod1_job (custom workspace set to main_job/workspace/modules/mod1)
    + workspace (empty)
于 2011-08-17T11:17:39.360 に答える
1

私は同じ問題に遭遇し、現在、プロジェクトごとにジョブを作成し、Copy Artifact Pluginを使用して、依存関係で Git の更新が行われた場合でも依存ジョブをビルドできるようにすることで解決しました (これは、ジョブの途中でのビルドを避けるためです)。依存しているプロジェクトに更新します)。

したがって、project_a は必要な最新の安定したアーティファクトを test_framework からコピーし、テスト フレームワークを更新すると project_a でビルドがトリガーされます。project_a は、Git の変更によって引き続きトリガーできます。test_framework の最新のアーティファクトを再度コピーするだけです。

于 2010-09-16T15:31:14.910 に答える