39

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

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

このブログ投稿も読みましたが、Pythonのバージョンが異なるだけで、すべてが同じマシン上に構築されます。

つまり、要するに、ほとんどの人は、多くの異なるプラットフォームを対象としたマルチ構成プロジェクトをどのように構成するのでしょうか。

4

9 に答える 9

42

2つのタイプのジョブには別々の機能があります。

  • フリースタイルのジョブ：これらを使用すると、単一のコンピューターまたはラベル（「Windows-XP-32」などのコンピューターのグループ）でプロジェクトを構築できます。
  • マルチ構成ジョブ：これらを使用すると、複数のコンピューターまたはラベル、あるいはその2つの組み合わせ（Windows-XP、Windows-Vista、Windows-7、RedHatなど）でプロジェクトを構築できます。互換性の確認や複数のプラットフォームの構築に役立ちます。 （qtプログラム？）

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

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

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

あなたがリンクする質問には公平な点がありますが、あなたの質問に直接関係しないものです。彼の場合、彼は複数構成のジョブAを持っていて、成功すると別のジョブBをトリガーしました。これで、複数構成ジョブで、構成の1つが失敗すると、ジョブ全体が失敗します（明らかに、プロジェクトをすべての構成で正常にビルドする必要があるため）。

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

于 2011-09-22T14:16:19.373 に答える
6

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

于 2012-09-29T03:38:08.147 に答える
4

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

于 2012-07-10T15:40:02.970 に答える
4

オプションは、スレーブ（windows、linux、...）と組み合わせてユーザー定義の軸を使用することです。したがって、組み合わせごとにフィルターを追加し、Conditional BuildStepプラグインを使用して、各plataform（Executarシェル）に固有のビルドステップを設定する必要があります。 、Windowsコマンド、...）

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

于 2013-06-21T01:55:19.443 に答える
2

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

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

于 2012-01-26T23:16:07.703 に答える
2

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

于 2012-10-19T03:52:57.880 に答える
1

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

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

ln -s /bin/true /bin/cmd

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

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

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

于 2013-09-20T11:05:34.023 に答える
1

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

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

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

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

于 2014-06-30T12:34:45.673 に答える
0

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

于 2015-08-17T13:34:13.837 に答える