さまざまなスレーブマシンでテストを実行するJenkins（Hudson）サーバーのセットアップがあります。私がやりたいのは、（リモートAPIを使用して）スレーブを再構成し、スレーブを再起動して変更が有効になるようにしてから、残りのテストを続行することです。私がこれまでに遭遇した2つのハードルがあります：
- Jenkinsジョブがスレーブで実行を開始すると、スレーブがダウンしたり、サーバーへのネットワーク接続を切断したりすることはできません。そうしないと、Jenkinsはすぐにテストに失敗します。通常、これは完全に望ましい動作だと思います。ただし、この場合、スレーブがオンラインに戻ってJenkinsが再接続できるようになるまで、またはスレーブがJenkinsに再接続するまで、Jenkinsが中断を受け入れてほしいと思います。
- スレーブにアタッチされているジョブでは、スレーブではなく、Jenkinsマスターでいくつかのビルドタスクを実行する必要があります。
これは可能ですか？これまでのところ、Jenkinsまたはそのプラグインを使用してこれを行う方法は見つかりませんでした。
編集-詳細説明 私は本当に、ジェンキンスのスレーブアーキテクチャが本当に好きです。すでに利用可能なプラグインと組み合わせると、スレーブへのジョブの取得、実行、および結果のプルバックが非常に簡単になります。また、一致するスレーブを選択する機能により、ジョブ/テストの自動配布が可能になります。
私たちの状況では、仮想化（VMware）スレーブマシンを使用しています。JenkinsがVMwarePowerCLIを使用して、スレーブで実行する必要があるときにVMを起動し、ジョブをスレーブに送信して結果をプルバックするスクリプトを作成するのは簡単でした。すべて良い。
ただし、各テストのセットアップの一部は、何らかの方法で仮想マシンをわずかに再構成することです。UACを無効にする、別のユーザーとしてログオンする、別のドライバーをインストールするなど。これらの変更を行うたびに、変更を有効にする前にテストVM/スレーブを再起動する必要があります。この再構成と再起動を処理するスレーブオンデマンドスクリプト（Launch Method =マスターでのコマンドの実行によるスレーブの起動）を作成できますが、ジョブを実行する前に実行する必要があります。ここで問題が発生します。構成変更のタイプは実行中のジョブに依存するため、スレーブを早期に構成することはできません。これは、スレーブの開始後にのみ発生します。
考えられる解決策
1）単一のVMで複数のスレーブインスタンスを使用します。これは機能しません-いくつかの構成は相互に排他的ですが、Jenkinsはそれを知りません。したがって、あるジョブに対して1つのスレーブ構成を開始し、別のジョブに対して別のスレーブを開始しようとします。両方のスレーブが同じVM上にあります。スレーブの起動はジョブの一部ではないため、ジョブをロックしてもこれを防ぐことはできません。
2）（最適）スレーブ接続が中断される可能性があることをジョブが認識できるようにするビルドステップ。Jenkinsがスレーブを再接続する方法を認識できるように、ビルドステップにいくつかのオプションを含める必要がある場合があります（スレーブは自動的に再接続し、Jenkinsはスクリプトを実行する必要があり、単純なSSHで十分です）。ビルドステップは、スレーブの切断を処理し、通常はジョブに失敗する切断を無視してから、再接続を実行します。スレーブがバックアップされて実行されると、次のビルドステップが発生する可能性があります。おそらく、スレーブが特定の時間内に再接続できない場合にジョブを失敗させるためのタイムアウト。
**現在の解決策**-最適
とは言えません現在、Jenkinsのスレーブ機能を使用できません。代わりに、WindowsおよびPowerShellスクリプトを使用してVMの電源をオンにし、構成を作成して再起動する一連のビルド手順（マスターで実行）を使用します。VMにはSSHサーバーが実行されており、これを使用してテストファイルをテストVMにアップロードし、リモートで実行します。次に、結果をダウンロードしてJenkinsに戻し、ジョブで処理します。このソリューションは機能的ですが、通常のJenkinsスレーブアプローチよりもはるかに多くの作業が必要です。また、スクリプトは単一のVMを対象としています。奴隷のプールを簡単に使うことはできません。