Jenkins + Cmake + JIRA =多个相互依赖项目的CI？ [英] Jenkins + Cmake + JIRA = CI of multiple interdependent projects?
问题描述
我们的系统中有许多小型项目在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 / lib
/ lib / lib4
/ lib / include
做一些工作创建一些CMakeLists.txt文件，并构建了大部分的libs和一些应用程序。我相当舒服使用cmake来构建。我做了这个与v2.6，我最近（一小时前）升级到2.8。以上每个项目都有自己的CMakeLists.txt文件，专门用于项目建设和安装（没有包装，但）。
我需要使用并强制执行持续集成。我已经安装和玩了Jenkins，从我看到的，我印象非常深刻。我也在评估JIRA做我们的问题跟踪。
只是为了让事情发生，我已经对所有的libs进行了cmake安装，所以应用程序可以在文件系统中找到它们。头文件安装到/ usr / local / include，libs安装到/ usr / local / lib。这是一件坏事吗？最好告诉cmake查找lib的源目录，使用导出界面或最近推出的 ExternalProject_Add ？
因为我要使用Jenkins，我不能保证cmake可以找到源码或构建目录。当然，我可以告诉Jenkins按顺序构建项目（或者至少首先构建依赖项）。如果对图书馆的更新打破了另一个项目的建设，那么我想这将取决于有3/4机智的人来确定这一点。
谢谢
只是为了让事情发生，我已经做了一个cmake安装在所有的libs，所以应用程序可以在文件系统中找到他们。头文件安装到/ usr / local / include，libs安装到/ usr / local / lib。这是一件坏事吗？这不是一件坏事，但是你的构建应该从头开始重现资源。如果事情需要在构建过程之外的系统中预先安装，可移植性和修复构建错误等问题将成为一个问题。如果你能够做到其他方式，如你所提到的我会建议的方式，但如果它将使你的构建更长，你需要感觉的东西。我的意识形态是一切都应该移动到一个新的Jenkins机器与一个新的安装在一滴帽子，这一次总是不可能实现，但一些努力。
因为我要使用Jenkins，所以我不能保证
cmake可以找到source或build目录。当然，我可以告诉
Jenkins按顺序构建项目（或至少，首先构建
依赖项）。如果对库的更新打破了
另一个项目的建设，那么我想这将取决于有3/4的机智
的人来确定这一点。
我在相互依赖的工作中做的事情之一是，在成功构建一个作业时触发依赖它的工作。例如，如果A依赖于B，而A失败，B将永远不会运行，谁创建了问题，构建A负责它，等等。这防止了破坏构建的级联影响，所有这些都是由破坏的依赖性导致的。我建议您将文件保存在其作业文件夹中的特定构建，并指定所需文件的位置的依赖关系。再次保持您的构建独立和干净。
我也在评估JIRA来执行我们的问题跟踪。
我强烈推荐JIRA作为公司的问题跟踪系统;您可能需要查看此 Jenkins插件进行集成。如果你使用git，你不介意托管你的代码在网站上，我会GitHub问题也一样。
Goodluck你似乎在正确的轨道上。
We have a number of small projects within our system running on Linux (Slackware 7-11, slowly migrating to RHEL 6.0). Around 50-100 applications and 15-20 libraries. Almost all our applications use one or more of our libraries. Our source tree looks something like this:
/app1
/app2
/app3
/include
/foo/app4
/foo/app5
/foo/app6
/foo/lib1
/foo/lib2
/lib/lib3
/lib/lib4
/lib/include
Now, I've done some work creating some CMakeLists.txt files and built most of the libs and some of the apps. I'm fairly comfortable with using cmake to build. I did this with v2.6, and I recently (an hour ago) upgraded to 2.8. Each of the above projects have their own CMakeLists.txt file specific to the project to do building and installation (no packaging, yet).
I have a requirement to make use of and enforce continuous integration. I've installed and played around with Jenkins, and from what I've seen I'm very impressed. I'm also evaluating JIRA to do our issue tracking.
Just to get things up and going, I've done a cmake install on all the libs, so the apps can find them in the filesystem. Headers are installed to /usr/local/include and libs to /usr/local/lib. Is this a bad thing to do? Would it be better to tell cmake to look for the lib's source directory, use the export interface or the recently introduced ExternalProject_Add?
Because I'm going to be using Jenkins, I cannot be guaranteed that cmake can find the source or build directory. Of course, I can tell Jenkins to build the projects in order (or at least, build the dependencies first). If an update to a library breaks the building of another project, then I guess it'll be up to someone with 3/4 of a wit to determine this.
Thank you in advance
Just to get things up and going, I've done a cmake install on all the libs, so the apps can find them in the filesystem. Headers are installed to /usr/local/include and libs to /usr/local/lib. Is this a bad thing to do?
No it is not a bad thing to do, but your build should reproduce resources from scratch. Things like portability and fixing build bugs will become an issue if things need to be pre-installed in the system outside of the build process. If you are able to do it other ways as you mentioned I would suggest that way, but if its going to make your build that much longer, its something you need to feel out. My ideology is everything should be movable to a new Jenkins machine with a fresh install at the drop of a hat, again this always isn't achievable, but something to strive for.
Because I'm going to be using Jenkins, I cannot be guaranteed that cmake can find the source or build directory. Of course, I can tell Jenkins to build the projects in order (or at least, build the dependencies first). If an update to a library breaks the building of another project, then I guess it'll be up to someone with 3/4 of a wit to determine this.
Well one of the things I do in interdependent jobs is that on the successful building of one jobs triggers the job that depends on it. So for example if A depends on B, and A fail, B will never be run and whoever created the issue in build A is responsible for it and so on. This prevents a cascading affect of broken build that all were caused by a broken dependency. I would suggest that you keep files in a particular build in its job folder and specify to the dependency the location of the required files. Again keep your builds separate and clean.
I'm also evaluating JIRA to do our issue tracking.
I highly recommend JIRA as an issue tracking system for company; You might want to look at this Jenkins plugin for integration. If your using git, and you dont mind hosting your code off site, I would GitHub issues a shot as well.
Goodluck you seem to be on the right track.
这篇关于Jenkins + Cmake + JIRA =多个相互依赖项目的CI？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
