私は最近 Jenkins の実験を始めましたが、マトリックス構成ジョブが何をすべきかについて非常に間違っているか、何か間違ったことをしています。すでに尋ねられた同様の質問を探してみましたが、ジェンキンスの専門用語にはまだ十分に慣れていません。おそらく、誰もが今までに尋ねたのはこれが初めてです！
次のようなディレクトリ構造を持つ svn にチェックインされたプロジェクトがあります。
./doc
./include/
./src/
./target
./target/linux-ARM
./target/linux-ARM/include
./target/linux-ARM/lib
./target/linux-ARM/src
./target/linux-i386
./target/linux-i386/include
./target/linux-i386/lib
./target/linux-i386/src
./target/linux-x86_64
./target/linux-x86_64/include
./target/linux-x86_64/lib
./target/linux-x86_64/src
./target/win32-i386
./target/win32-i386/include
./target/win32-i386/lib
./target/win32-i386/src
./target/win32-x86_64
./target/win32-x86_64/include
./target/win32-x86_64/lib
./target/win32-x86_64/src
プラットフォームに依存しないコードは ./src 内にあり、すべてのプラットフォーム固有のコードは適切なターゲット ディレクトリにあります。ジェンキンスでマトリックス構成プロジェクトを使用できるように、このディレクトリ構造を具体的に作成しました。
私が定義する唯一の軸は「プラットフォーム」と呼ばれ、値は linux-ARM、linux-i386、linux-x86_64、win32-i386、および win32-x86_64 です。
次のビルドステップを指定するだけで、すべてが処理されると思いました。
chmod 777 ./target/$platform/build
chmod 777 ./target/$platform/deploy
./target/$platform/build
./target/$platform/deploy
問題は、ジェンキンスがこの仕事を適切に行い、エラーを報告しないことです。しかし、(jenkins 内で) ワークスペース セクションに移動すると、プロジェクトのビルドにまったく異なるディレクトリ構造が使用されていることがわかります。基本的に、プロジェクト全体が構成ごとに新たにエクスポートされ、./$platform ディレクトリ内に配置されます。
./doc // <--- this one is actually thesame
./include/
./platform/
./platform/linux-ARM
./platform/linux-ARM/doc // <--- as this one
./platform/linux-ARM/include
./platform/linux-ARM/src
./platform/linux-ARM/target
./platform/linux-ARM/target/linux-ARM
./platform/linux-ARM/target/linux-ARM/include
./platform/linux-ARM/target/linux-ARM/lib
./platform/linux-ARM/target/linux-ARM/src
./platform/linux-ARM/target/linux-i386
./platform/linux-ARM/target/linux-i386/include
./platform/linux-ARM/target/linux-i386/lib
./platform/linux-ARM/target/linux-i386/src
./platform/linux-ARM/target/linux-x86_64
./platform/linux-ARM/target/linux-x86_64/include
./platform/linux-ARM/target/linux-x86_64/lib
./platform/linux-ARM/target/linux-x86_64/src
...
...
./src/
./target
./target/linux-ARM
./target/linux-ARM/include
./target/linux-ARM/lib
./target/linux-ARM/src
./target/linux-i386
./target/linux-i386/include
./target/linux-i386/lib
./target/linux-i386/src
./target/linux-x86_64
./target/linux-x86_64/include
./target/linux-x86_64/lib
./target/linux-x86_64/src
./target/win32-i386
./target/win32-i386/include
./target/win32-i386/lib
./target/win32-i386/src
./target/win32-x86_64
./target/win32-x86_64/include
./target/win32-x86_64/lib
./target/win32-x86_64/src
これが意図された動作であるとは想像できません。それでも、jenkins がプロジェクトに問題はないと主張している限り、私は文句を言うつもりはありません。ただし、doxygen を使用してドキュメントを生成する場合は問題になります。Doxygen は再帰スキャンにエイリアン ./$platform ディレクトリを含め、異なる場所にある 6 つのまったく同じソース ファイルのドキュメントを解析しようとします。
これを回避する方法はありますか？同じプロジェクトを 6 回エクスポートする理由がわかりません。それとも、これは意図された動作であり、5 つの別々のフリー スタイル ジョブを使用するように切り替える必要がありますか?