gmake で通常の C コードをビルドする場合に、1 つのマスターと複数のスレーブを持つようにシステムを構成する方法は? スレーブはどのようにマスターからワークスペースにアクセスできますか? NFS 共有はうまくいくと思いますが、それが不可能な場合、他のオプションはありますか?
http://wiki.hudson-ci.org/display/HUDSON/Distributed+buildsはありますが、ワークスペースの共有がどのように処理されるか理解できませんか?
同期？マスターから: SCM ジョブ -> 完了 -> すべてのスレーブへの rsync -> ビルド ジョブ、およびスレーブで完了した場合 -> マスターへの rsync ワークスペース?
概念実証または実際のソリューションはありますか?
Hudson がスレーブ ノードでビルドを実行すると、そのノードのソース管理からチェックアウトされます。他のファイルをマスター ノードからコピーする場合、またはビルド後に他のアイテムをマスター ノードにコピーする場合は、Copy to Slave プラグイン を使用できます。
それは確かに遅い答えですが、他の人を助けるかもしれません。
私は現在「コピーアーティファクトプラグイン」を使用しており、素晴らしい結果が得られています。 http://wiki.hudson-ci.org/display/HUDSON/Copy+Artifact+Plugin
物事を行うための1つの方法、他の方法が存在します。
ワークスペースは、複数のマシンのそれぞれにディレクトリとして存在するため、複数のマシンに分散されている場合、実際には共有されません。アイテムの調整を解決するために、あるワークスペースから別のワークスペースに配布する必要のあるアイテムは、SCPを介して中央リポジトリにコピーされます。
これは、中央リポジトリにアイテムが到着するのを待つ必要があるタスクがあることを意味します。これを修正するために、必要なアイテムの存在についてSCPを介してリポジトリをポーリングするシェルスクリプトをタスクに実行させます。5分後にアイテムが利用できない場合はエラーになります。
これの唯一の欠点は、ビルドを同じページに保持するためにパラメーター（ビルド番号）を渡す必要があることです。これにより、1つのビルドが以前のバージョンのビルドされたアーティファクトを取得できなくなります。それと、SSHスクリプトを実行するときにパスワードを渡す必要がないように、多くのSSHキーを設定する必要があります。
私が言ったように、理想的な解決策ではありませんが、Hudsonの特定のリリース（およびSSHサーバーのセット）のsshアーティファクトグラブコードよりも安定していることがわかりました。
欠点の1つは、ほとんどのLinuxマシンのSSHサーバーが実際にパフォーマンスを欠いているようです。私のようなソリューションは、SSHサーバーを大量の接続でほぼ同時に受信する傾向があります。同じことが発生した場合は、タイマー遅延を追加するか（簡単で不完全なソリューション）、高性能パッチを使用してSSHサーバーを再構築できます。いつの日か、SSHサーバーのセキュリティに悪影響を与えない限り、高性能パッチがSSHサーバーのベースコードに組み込まれることを願っています。