我最近开始尝试使用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
我无法想象这是预期的行为。然而，只要詹金斯声称该项目没有问题，我就不会抱怨。但是当你想使用doxygen生成文档时，它就成了一个问题。 Doxygen将在其递归扫描中包含异类./$platform目录，并将尝试解析不同位置的6个完全相同的源文件的文档。
有没有办法解决这个问题？我认为没有理由将同一个项目导出6次。或者这是预期的行为，我应该切换到使用5个单独的自由风格的工作吗？
答案 0 :(得分：1)
Jenkins总是为矩阵作业做到这一点。我认为原因是它们应该具有独立的工作空间，因此构建不会相互影响。
您可以通过排除Doxyfile中的platform-folder或仅为其中一个子工作运行Doxygen来解决您的Doxygen问题。