我自己的 CI 长久以来都是手动配置 Free-Style Project，有很多重复的部分很不方便统一修改。所以就打算搞得比较自动化一点方便批量修改任务，一开始是想用什么 Template 之类，但是后来就发现了 Job DSL 和 Pipeline。
姑且来说，这两个解决的问题有重合的部分，但是也有不一样的地方。Pipeline 基本就是用一个 Groovy 的子集（还是相似的东西？），来描述一个 Job，支持的功能比较多。而 Job DSL 是用 Groovy 的一个脚本来生成 Job。实践当中你可以两个都用。
Pipeline 最基本的用法就是在代码库里面放一个 Jenkinsfile，里面描述 pipeline。当然这么做是有缺点的，因为你还是没有自动化多个不同的项目的任务生成。总之是一个类似把 Jenkins 当作 travis 的用法。
我踩的第一个坑就是没有意识到这两个东西虽然都是 Groovy，但是使用的是两套 API。需要分别查看各自的文档。我犯的一个错误就是把 Pipeline 里面的用法放到 Job DSL 里面用……结果当然是没法通过了，而且我还一直没有意识到这个问题折腾了好久。
总之，最后总算是搞清了这个问题，然后我发现我一开始写的 Job DSL 还是生成了 Free Style Job，所以开始思考我到底要不要用 Pipeline。有这么几个问题，例如，我用的一个 Jenkins Plugin CMake 还不支持 Pipeline，所以就有些纠结到底要不要用这个。
我作为参考的 KDE 是选择都用的，但是和编译工具链的胶水层是通过自己写的 Python 脚本来实现（当然我相信他们是有正当的理由）。反过来说我使用那个 CMake 插件也并没有特别实现什么…所以我其实并不需要 Pipeline 提供的复杂功能。Job DSL 的支持疑似比较全，所以我的一个结论就是，如果从前你就用 Free-Style Job 并且你也没有特别的需要新的功能，用 Job DSL 生成 Free-Style Job 就好。Pipeline 才能解决你的问题的时候，或者想要在源码库里面放个 Jenkinsfile 的方式来定义编译过程，你可以考虑 Pipeline。
