詹金斯的规则和食谱构建工作

时间:2017-02-20 09:47:46

标签: jenkins groovy makefile continuous-integration

目前我们正在jenkins中为CI构建添加groovy pipeline scripts。有些东西可以并行化,有些依赖于其他构建步骤的输出。

parallel "does_not_depend_on_X": { upfront_tests(); },
"depends_on_x": { produce_x(); integration_tests(); publish_test_results()}

喂!我认识到了! make通过规则和食谱解决了这个问题!

all: upfront_tests test_results x

test_results: x
    integration_tests > test_results

x: x_inputs
    produce_x $*

upfront_test_results:
    upfront_tests

有没有办法用jenkins和groovy实现这种有向无环图排序/并行化?

1 个答案:

答案 0 :(得分:1)

我必须说这是一个关于头脑风暴的非常有趣的问题。 AFAIK没有办法使用该语法。 Jenkins支持两种定义管道的方法:脚本化管道(使用Groovy的命令式样式)和声明性管道(更结构化的方式),尽管我老实说不认为后者是真正的声明式(您仍然需要定义要做什么以及如何做),但由于其简化的语法,可能有助于构建图形编辑器。两者都记录在案here,我不知道有任何其他方式来编写它们。

然而,有一点需要注意的是,Make(和一般的构建工具)和Jenkins是非常不同的工具,适用于非常不同的场景。 Make是一个构建程序(主要是C或C ++程序)的工具,而Jenkins是一个功能齐全的 CI自动化引擎,可用于实现复杂的持续交付流程从SCM签出开始,最后在环境中启动并运行应用程序(通常已通过一组测试)。如果构建工具依赖于有向非循环图,则Jenkins管道实际上代表了跨阶段的线性工作流。所以在某种程度上,让Jenkins扩展Make的想法没有意义。即使在构建工具中,它们也倾向于更改的使用方式。例如,Maven和Gradle没有Ant或Make具有的依赖项或先决条件目标的概念。他们仍然知道运行任务的顺序,但用户不必明确指定它们。

另一件事是我们必须及时回顾Makefile规则背后的想法。它们是一种告诉Make哪些文件根据修改的源文件进行编译的方法,目的是避免在大项目中完全构建。从根本上说,Make中的依赖项只是检查上次修改时间的源文件。在Jenkins中,除了从源文​​件生成目标文件的步骤之外,这个概念不存在。

现在你可以争辩说Jenkins仍然可以使用依赖的概念作为在执行当前步骤之前要完成的任何先决条件步骤,而不仅仅是源文件以在上次修改时进行检查。换句话说,我们可以将声明性管道写成:

pipeline {
   agent any 

   stages {              
       stage(name='Test', depends='Build'){
           steps {
               sh 'make check'
               junit 'reports/**/*.xml' 
           }
       }
       stage('Build') {
           steps { 
               sh 'make' 
           }
       }
       stage(name='Deploy', depends='Test') {
           steps {
               sh 'make publish'
           }
       }
   }
}

虽然理论上这会使语法更具说明性(因为代码中的阶段顺序不再重要),但实际上它是一个无用的特性,因为顺序足以表示阶段序列。