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构建相当满意。我在2.6版本中做到了这一点，最近(一个小时前)我升级到了2.8。上述每个项目都有自己的特定于该项目的CMakeLists.txt文件来进行构建和安装(尚未打包)。
我有一个利用和执行持续集成的需求。我已经安装了Jenkins并与之打交道，从我看到的情况来看，我印象非常深刻。我也在评估JIRA来做我们的问题跟踪。
为了让一切顺利进行，我在所有库上执行了cmake安装，这样应用程序就可以在文件系统中找到它们。头文件安装到/usr/local/include，libs安装到/usr/local/lib。这是一件坏事吗？告诉cmake使用export interface或最近引入的ExternalProject_Add来查找库的源目录是不是更好？
因为我将使用Jenkins，所以不能保证cmake可以找到源代码或构建目录。当然，我可以告诉Jenkins按顺序构建项目(或者至少先构建依赖项)。如果一个库的更新破坏了另一个项目的构建，那么我猜这将由一个有3/4智慧的人来决定。
提前谢谢你
回答 1
Stack Overflow用户
发布于 2011-07-14 22:33:46
我已经在所有的库上安装了cmake
，这样应用程序就可以在文件系统中找到它们了。头文件安装到/usr/local/include，libs安装到/usr/local/lib。这是一件坏事吗？
不，这不是一件坏事，但您的构建应该从头开始重新生成资源。如果在构建过程之外需要在系统中预先安装一些东西，那么像可移植性和修复构建错误这样的事情就会成为一个问题。如果你能像你提到的那样用其他方式来做，我会建议你这样做，但是如果这会让你的构建变得更长，那么你需要去摸索一下。我的想法是，一切都应该移动到新的Jenkins机器上，并立即进行全新安装，同样，这永远不是可以实现的，而是需要努力的东西。
因为我将使用Jenkins，所以不能保证
可以找到源代码或构建目录。当然，我可以告诉Jenkins按顺序构建项目(或者至少先构建依赖项)。如果一个库的更新破坏了另一个项目的构建，那么我猜这将由一个有3/4智慧的人来决定。
我在相互依赖的作业中做的一件事是，在成功构建一个作业时，会触发依赖它的作业。例如，如果A依赖于B，而A失败了，那么B将永远不会运行，并且无论是谁在构建A中创建了这个问题，都要对此负责，以此类推。这防止了所有由损坏的依赖项引起的损坏构建的级联影响。我建议您将特定构建中的文件保存在其作业文件夹中，并为依赖项指定所需文件的位置。同样，让你的构建保持独立和整洁。
我也在评估JIRA来做我们的问题跟踪。
我强烈推荐JIRA作为公司的问题跟踪系统；您可能需要考虑使用this Jenkins插件进行集成。如果你使用git，并且你不介意在站点之外托管你的代码，我也会在GitHub上发布一张照片。
祝你好运，你似乎走在正确的轨道上。
https://stackoverflow.com/questions/6216549
复制相似问题
腾讯云开发者
