我对Jenkins管道相对较新,并想知道是否可以将我当前的构建配置移植到Jenkins文件。
目前,每个项目都有一个CI作业,只要有人签入就会建立。这只是一个构建检查,不进行测试或静态代码分析。 第二个Job完成整个构建,包括长时间运行的集成测试和sonarqube分析。无论这个特定项目的变化是否发生,第二个计划每天运行一次(每晚一次)。
现在,如果我想将该配置移植到Jenkins Pipeline脚本,我显然可以使用单独的脚本配置两个作业,但更有趣的部分是将它包装到Jenkins文件中,这样我就可以使用Multibranch Pipeline作业了输入并且不必重复SCM之外的任何配置。
问题是,如果可以将构建步骤(并将之前不再需要的构建中的步骤中止)推迟到另一个时间表 - 例如仅在每晚的基础上运行集成测试?其他人如何采用快速构建检查的问题与在每次签入时可能没用的长期运行任务?
我还没有看到为Jenkins文件选择另一个名称的可能性(在multibranch管道作业类型中),因此可以有一个文件用于CI作业,另一个文件用于夜间。评估作业名称的脚本内部的条件可能是可能的,但对我来说看起来并不“正确”,并且它不能解决每天晚上强制构建的问题。
感谢您的任何想法 丹尼尔
答案 0 :(得分:4)
现在我有更多的时间去调查,似乎有几种方法可以去。
以下代码仅显示了我认为可行的方式。我没有这样做,所以要做好一些调整的准备:
node {
stage('build'){
// sh 'mvn install'
// most likely you'll need some stashing here to restore
// the current state in the next node
}
}
// it' essential to leave the node or you'll block the executor
stage('acknowledge'){
// https://jenkins.io/doc/pipeline/steps/pipeline-milestone-step/#milestone-the-milestone-step-forces-all-builds-to-go-through-in-order
milestone // mark before entering
try {
// here one needs to implement the magic to calculate how much time is left to the regular nightly
// remember to slightly decrease the time for every build, so that the last will be the first to continue
def timeToNightly = calculateTimeToNightly()
// https://jenkins.io/doc/pipeline/steps/workflow-basic-steps/#code-timeout-code-enforce-time-limit
timeout(time: timeToNightly, unit: 'MILLISECONDS'){
// having a input leaves the option to continue a build before the timeout is reached
input 'continue with integration tests?'
}
} catch(e) {
// so it's time for the daily hardwork
}
milestone // abort all older builds
}
node {
stage('test: integration'){
// possibly unstash previous build files
// sh 'mvn verify'
}
}
可以根据SCM更改,用户或计时器触发的构建,迭代记录器并分阶段停用功能。 https://github.com/jenkinsci/pipeline-examples/blob/master/pipeline-examples/get-build-cause/getBuildCause.groovy
因此,您需要将TimerTrigger添加到满足您需求的构建中,例如:只有每个月的第二个星期四(从上面的变体可能很难)。 https://jenkins.io/doc/pipeline/steps/workflow-multibranch/#properties-set-job-properties
properties([
pipelineTriggers([
// this is a timer trigger you may adjust the cron expression to your needs
cron('@daily')
])
])
node {
stage('build'){
// sh 'mvn install'
}
}
// here you'll have to go over the build causer and adjust the return value accordingly
if (isTriggeredByTimer()) {
node {
stage('test: integration'){
// sh 'mvn verify'
}
}
} else {
// repeat the stages here so they won't disappear in the job view
// doing this outside a node is better than to block a build slot first
stage('test: integration'){
echo 'Skipped testing for this build - it not the time yet.'
}
}
我进一步调整了这一点以提供作业参数,以便用户可以做出自己的决定(进行测试或仅进行静态代码分析,或者两者都进行,或者都不进行...)。
希望有所帮助。
至于我,现在我看到结构化管道提供的所有潜力(声明性更容易适应,但不是那么强大)来调整构建,中止旧的,限制可锁定资源的执行,并继续只使用最新的(里程碑),我可能会尝试继续执行每一步,只让最新的胜利。
答案 1 :(得分:0)
我一直想要完成类似的事情。我们想要的管道看起来像这样:
我想我可以在Jenkins文件中通过在env.JOB_NAME
对于第一部分,我理想情况下使用multibranch来构建和测试功能分支,但只在env.BRANCH_NAME=="master"
这是我目前的计划,但尚未完成。如果你找到一种安排阶段的方法,我很乐意听到更新。