Jenkins + Cmake + JIRA = 多个相互依赖项目的 CI？

我们的系统中有许多小项目在 Linux 上运行（Slackware 7-11，正在慢慢迁移到 RHEL 6.0）。大约 50-100 个应用程序和 15-20 个库。我们几乎所有的应用程序都使用我们的一个或多个库。我们的源树看起来像这样：

/app1
/app2
/app3
/include
/foo/app4
/foo/app5
/foo/app6
/foo/lib1
/foo/lib2
/lib/lib3
/lib/lib4
/lib/include

现在，我已经完成了创建一些 CMakeLists.txt 文件的工作，并构建了大部分库和一些应用程序。我对使用 cmake 构建相当满意。我用 v2.6 做到了这一点，最近（一小时前）升级到了 2.8。上述每个项目都有自己的 CMakeLists.txt 文件，该文件特定于该项目来进行构建和安装（尚未打包）。

我需要使用并强制执行持续集成。我已经安装并使用了 Jenkins，从我所看到的来看，我印象非常深刻。我还在评估 JIRA 来进行问题跟踪。

为了让事情顺利进行，我在所有库上进行了 cmake 安装，以便应用程序可以在文件系统中找到它们。标头安装到 /usr/local/include ，库安装到 /usr/local/lib 。这是一件坏事吗？最好告诉 cmake 查找 lib 的源目录，使用导出接口 http://www.cmake.org/Wiki/CMake%3aExportInterface或者最近推出的外部项目_添加 http://www.kitware.com/products/html/BuildingExternalProjectsWithCMake2.8.html?

因为我将使用 Jenkins，所以我不能保证 cmake 可以找到源或构建目录。当然，我可以告诉 Jenkins 按顺序构建项目（或者至少首先构建依赖项）。如果对库的更新破坏了另一个项目的构建，那么我想这将由具有 3/4 智慧的人来确定。

先感谢您

为了让事情顺利进行，我在所有库上进行了 cmake 安装，以便应用程序可以在文件系统中找到它们。标头安装到 /usr/local/include ，库安装到 /usr/local/lib 。这是一件坏事吗？

不，这并不是一件坏事，但是您的构建应该从头开始重现资源。如果需要在构建过程之外将东西预先安装在系统中，那么可移植性和修复构建错误之类的事情将成为一个问题。如果您能够像您提到的那样以其他方式做到这一点，我会建议您这样做，但如果它会让您的构建时间更长，那么您需要摸索一下。我的理念是，一切都应该可以移动到新的 Jenkins 机器上，并立即进行全新安装，这始终是不可能实现的，但却是值得努力的目标。

因为我要使用 Jenkins，所以我不能保证 cmake 可以找到源或构建目录。当然，我可以告诉 Jenkins 按顺序构建项目（或者至少构建 首先是依赖关系）。如果对库的更新破坏了 另一个项目，那么我想这将取决于有 3/4 智慧的人 来确定这一点。

我在相互依赖的工作中所做的一件事是，成功构建一项工作会触发依赖于它的工作。例如，如果 A 依赖于 B，并且 A 失败，则 B 将永远不会运行，并且在构建 A 中创建问题的人应对此负责，依此类推。这可以防止由损坏的依赖项引起的损坏构建的级联影响。我建议您将特定构建中的文件保存在其作业文件夹中，并向依赖项指定所需文件的位置。再次保持您的构建独立且干净。

我还在评估 JIRA 来进行问题跟踪。

我强烈推荐 JIRA 作为公司的问题跟踪系统；您可能想看看this https://wiki.jenkins-ci.org/display/JENKINS/JIRA+Plugin用于集成的 Jenkins 插件。如果您使用 git，并且您不介意将代码托管在异地，我也会在 GitHub 上发布一个镜头。

祝你好运，你似乎走在正确的轨道上。