Gitlab CI的精细化控制
当CI复杂到一定程度之后,就会衍生出各种各样的细致的控制需求。Gitlab CI默认的控制器能实现一定程度的控制。
失败时继续执行后续任务
Gitlab CI中默认情况下,如果上个阶段中有任务未成功执行,则下个阶段会被取消。这是因为它默认配置了 when: on_success 的条件,只有当前面的任务完成时,才会执行后续任务。
如果想接受一个任务失败,不阻塞后续任务,有两个方式能实现:
- 设置此任务的属性,allow_failure: true 参考allow_failure说明
- 设置此任务后续任务的属性,when: always 参考when的说明
类似地,还可以设置任务失败后的后续处理等。
自动取消过时的pipeline
当提交比较频繁时,可能会产生多个pipeline排队的情况。如果每次pipeline都是可以替代之前的pipeline的,那只有最新的commit需要执行pipeline,其余的已经没有意义了。
这种情况下,可以设置Gitlab自动取消过时的pipeline。
在"Settings->CI/CD"中,找到"Auto-cancel redundant, pending pipelines",勾选上它就可以了。
失败后自动重试
Gitlab 中提供了retry选项,可以设置任务失败后自动重试,最多重试两次,即总共3次。
且失败的时候,可以限制重试的原因。示例:
1test: 2 script: rspec 3 retry: 4 max: 2 5 when: 6 - runner_system_failure 7 - stuck_or_timeout_failure
具体的用法可参考官方文档:retry
自动取消过时的Job
Gitlab v12.3之后提供了新的控制选项:interruptible,相较于Gitlab仓库中设置的"Auto-cancel redundant, pending pipelines",它的控制维度更细,细化到了一个Job的级别。
可惜的就是依赖的版本比较高,目前还没用上过。
如果想要在旧版Gitlab中实现类似的效果,可利用webhook技术,在本文的最后部分会提到。
跳过pipeline
如果在CI中涉及到自动修改代码的场景,有可能会希望修改之后的代码不再触发CI。
这种情况下,可以在提交信息中加上[skip ci]
或[ci skip]
,就可以自动跳过了。
Webhook
最后,假如有Gitlab中暂不支持的功能需求,或者用的是Gitlab旧版本,没有某个需求。可以考虑使用webhook机制,自定义控制。
关于Webhook相关的介绍,可参考Gitlab官方文档:Webhooks。
它的原理,简要地说就是在Gitlab仓库的各项事件发生时,Gitlab服务器可以调用一个外部服务,将相关信息发送给它。在这个服务中,配置上Gitlab Token就可以通过API或者一些封装SDK,如nodejs中的gitbeaker,来操作Git仓库,控制它的各项内容了。