質問

現在のBuildbotセットアップを置き換えるために、Hudsonを試しています。 gitプラグインをインストールしました。現在の設定は次のとおりです。

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

今、 project_a をビルドするために、複数のgitリポジトリ(上記のもの)を持つ新しいジョブを追加しました。 test_framework がその階層を必要とするため、Hudsonがリポジトリを $ WORKSPACE の下の異なるディレクトリに複製することを望みました。しかし、ハドソンは代わりにすべてを $ 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リポジトリを作成する必要がありますか?

役に立ちましたか?

解決

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


セットアップチェーン

project_aのジョブ構成で、[ビルド後のアクション]までスクロールし、[他のプロジェクトをビルド...]をオンにします。ビルドするプロジェクトとしてtest_frameworkを入力します。

test_frameworkのジョブ設定で、Poll SCMが未チェックであること、および他のプロジェクトの後にビルドがproject_aに設定されていることを確認します。


仕組み

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

他のヒント

「他のプロジェクトを構築する」の問題解決策は、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を使用してビルドをトリガーします。

この質問は非常に古いことはわかっていますが、同じ問題にぶつかり、このページを使用して、本当にうまく機能していると思われる独自のソリューションを具体化しました(多少複雑になっていますが)。このソリューションの功績のほとんどはクリントンにあるはずです(この答えを提出するのが面倒なのは、彼の答えが同じベースディレクトリにある必要のある複数のリポジトリに対応していないようです)。

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

手順:

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

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

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

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

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

3)3つのタスクを連結します。プルタスクの順序は重要である場合と重要でない場合があります(私よりもわかりやすい)が、ソース管理のないタスクがチェーンの最後のリンクである必要があります。

同じ問題にぶつかり、現在、各プロジェクトのジョブを作成し、アーティファクトプラグインをコピーして、依存関係でGit更新が行われた場合でも依存ジョブをビルドできるようにします(これは依存するプロジェクトの更新の途中でビルドを回避するためです) 。

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

あなたが説明している問題は、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)
ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top