web-dev-qa-db-ja.com

Jenkinsおよびマルチ構成（マトリックス）ジョブ

Jenkinsには、マルチ構成プロジェクトとフリースタイルプロジェクトプロジェクトの2種類のジョブがあるのはなぜですか？どちらかを選択すると、もう一方に簡単に変換できないことをどこかで読みました。将来の変更に対して安全にするために、常にマルチ構成プロジェクトを選択しないのはなぜですか？

WindowsとUnix（および他のプラットフォーム）の両方でビルドするプロジェクトのビルドをセットアップしたいと思います。私は この質問 ）を見つけました。これは同じことを尋ねますが、実際には答えが得られません。プラットフォームごとに1つずつ、3つのフリースタイルプロジェクトではなく3つのマトリックスプロジェクトが必要なのはなぜですか？プラットフォームと（たとえば）1つの軸にgccバージョンを、もう1つの軸に（私の）ソフトウェアバージョンを使用して、すべてを1つのマトリックスに保持できないのはなぜですか？

このブログ投稿 も読んでいますが、同じマシンですべてをビルドしますが、Pythonバージョン。

要するに、多くの人々は、多くの異なるプラットフォームをターゲットとするマルチ構成プロジェクトをどのように構成するのでしょうか？

jenkinscontinuous-integrationmulti-configuration
38
joscarsson

2種類のジョブには別々の機能があります。

  • フリースタイルのジョブ：これらは、単一のコンピューターまたはラベル（「Windows-XP-32」などのコンピューターのグループ）でプロジェクトをビルドできます。
  • 複数の構成ジョブ：これらにより、複数のコンピューターまたはラベル、またはWindows-XP、Windows-Vista、Windows-7、RedHatなどの2つの組み合わせでプロジェクトを構築できます-互換性の確認または複数のプラットフォーム向けのビルド（qtプログラム？）

WindowsとUnixでビルドするプロジェクトがある場合、2つのオプションがあります。

  • 構成ごとに個別のフリースタイルジョブを作成します。この場合、各ジョブを個別に保守する必要があります
  • one multi-configuration jobがあり、2つ（またはそれ以上）のラベル/コンピューター/スレーブを選択します-Windows用に1つ、Unix用に1つ。この場合、ビルドのために1つのジョブを維持するだけです

1つの軸にgccバージョンを、別の軸にソフトウェアバージョンを保持できます。できないはずの理由はありません。

リンクする質問には公正な点がありますが、あなたの質問に直接関係しないものです：彼の場合、彼は複数の構成の仕事を持っていました[〜＃〜] a [〜＃〜] 、-成功すると-別のジョブをトリガーしました[〜＃〜] b [〜＃〜]。現在、マルチ構成ジョブでは、構成の1つが失敗すると、ジョブ全体が失敗します（明らかに、すべての構成でプロジェクトを正常にビルドする必要があるため）。

私見、複数のプラットフォームで同じプロジェクトを構築するためのより良い方法は、マルチ構成スタイルのジョブを使用することです。

42
Sagar

もう1つのオプションは、pythonビルドステップを使用して現在のOSを確認し、適切なセットアップまたはビルドスクリプトを呼び出すことです。pythonスクリプトでは、更新された環境をファイルに追加し、その後のビルド手順でEnvInjectプラグインを使用して環境を再度挿入しますビルド環境のサイズに応じて、SConsなどのマルチプラットフォームビルドツールを使用することもできます。

6
Michael

オプションは、スレーブ（windows、linux、...）と組み合わせたユーザー定義の軸を使用することです。そのため、各組み合わせにフィルターを追加し、Conditional BuildStepプラグインを使用して、各plataform（Executar Shell 、Windowsコマンド、...）

このリンクにはチュートリアルがありますが、ポルトガル語ですが、画像に基づいて簡単に解決できます... http://manhadalasanha.wordpress.com/2013/06/20/projeto-de-multiplas- configuracoes-matrix-no-jenkins /

4
pauloremoli

ソースコードでチェックインするスクリプト（例build）とバッチファイル（例build.bat）を作成できます。 Jenkinsのビルドステップでは、$ WORKSPACE/buildを呼び出すことができます-Windowsはbuild.batを実行しますが、Linuxはbuildを実行します。

3
decocijo

設定マトリックス軸を定義するときに、jenkinsが作成する変数を使用できます。例：OSTYPEという名前のスレーブ軸を作成し、2つのスレーブ（WindowsとLinux）を確認します。次に、2つの別個のビルドステップを作成し、OSTYPE環境変数を確認します。

代わりに、Pythonなどの改良されたスクリプト言語を使用できます。Pythonはマルチプラットフォームであり、スレーブの名前に関係なく、1つのビルドステップで同じ機能を実現できます。

2
Lucas Ces

Windowsなどでマトリックスルートを使用する場合は、XShellプラグインが必要です。 cmdには「build.bat」、bashには「build」などの2つのビルドスクリプトを作成し、XShellに「build」を実行するように指示します。いずれの場合も、正しいものが実行されます。

2
Todd Greer

なぜあなたは常にマルチコンフィギュレーションジョブタイプを選択しないのですか？

いくつかの理由が思い浮かびます：

  1. ジョブは簡単に作成および構成できる必要があるためです。ご使用の環境でジョブを構成することが難しい場合、おそらくjenkinsジョブの範囲外で何か間違ったことをしていることになります。その1つのジョブを作成できて、それが最終的に実行されたことに満足しており、この作業全体をやり直すことに消極的である場合は、改善を試みる必要があります。
  2. マルチ設定ジョブはより複雑だからです。通常、メインジョブとさまざまなサブジョブ変数の両方について考える必要があり、管理しにくいレベルまで複雑さを増す傾向があります。そのため、単一のジョブシナリオでは、おそらくその複雑さを使用しないという考えを無駄にし、ビルド変数を拡張すると、物事が間違った方向に成長する可能性があります。デフォルトとして単純なジョブを使用し、複数の構成が必要な場合にのみ複数の構成ジョブを使用することをお勧めします。
  3. 複数の構成ジョブを実行するには、単一のジョブよりも多くのスレーブ上のジョブスロットが必要になる場合があるためです。常に、特別な非表示スロットで実行されるマスタージョブがあり（それ自体は問題ありません）、サブジョブをトリガーしますが、これらのサブジョブ自体がサブジョブをトリガーする場合は、デッドロックが発生する可能性があります。スロットよりもサブジョブが多く、一部のサブジョブは再びサブジョブをトリガーします。サブジョブは、開いているスロットがないため実行できません。この問題は、スレーブでいくつかの構成設定を使用することで回避できますが、複数のマルチジョブが同時に実行されている場合にのみ発生する可能性があります。

本質的に、マルチ構成ジョブはより複雑なものであり、必要な場合を除き複雑さを避ける必要があるため、通常のフリースタイルジョブの方がデフォルトとして適しています。

1
Sven

Windowsでバッチファイルを実行し、Unixでシェルスクリプトを実行するハック：

Unixでは、バッチファイルを終了ステータス0で終了させます。

ln -s /bin/true /bin/cmd

Windowsでは、true.exeを見つけ、sh.exeという名前を付けて、PATHのどこかに配置します。

または、Windowsにsh.exeがインストールされている場合（Cygwin、Git、またはその他のソースから）、これをJenkinsのシェルスクリプトの先頭に追加します。

[ -n "$WINDIR" ] && exit 0

1
larsch

ジョブを実行するスレーブを選択する場合は、マルチ構成プロジェクトを使用する必要があります（そうしないと、実行するスレーブを選択または制限できません。3つの方法がありますが、すべてを試してみました（Tieプラグインはマスタージョブでのみ動作します。[高度なプロジェクトオプションで制限]もロックセーフトリガーではないため、今日正しく動作することが証明されているスレーブ軸を使用します。）

0
igraczech