Jenkins中的矩阵配置从SVN生成奇怪的工作空间

Question

我最近开始对Jenkins进行试验，或者对于应该执行矩阵配置作业应该做的事情很误解，或者我做错了什么。 我已经尝试寻找已经问过的类似问题，但是我对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内，所有平台特定的代码位于相应的目标目录中。 我专门制作了此目录结构，以便可以在jenkins中使用矩阵配置项目。

我定义的唯一轴称为“平台”，其值包括：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个独立的自由样式作业吗？

Answer 1

詹金斯（Jenkins）总是对矩阵工作这样做。 我认为原因是它们应该具有独立的工作区，因此构建不会相互影响。

您可以通过在Doxyfile排除平台文件夹或仅对其中一个子作业运行Doxygen来解决Doxygen问题。