Jenkins-pipeline学习笔记–自动构建的原始配置以及pipeline中的用法(三) |坐而言不如...

系列汇总

大多数时候，我们做的流水线都希望通过开发人员push代码触发Jenkins的自动构建，在还没有深入接触到Jenkinsfile语法之前，我都是用传统的配置方式对这一功能进行的配置。

今天就专门说明一下这个配置，先介绍一下传统配置流程，再介绍Jenkinsfile中的简便方式。

1，传统方式。

本文基于第一篇的从一个简单的构建开始进行补充配置，事实上也就那么几个配置项。

gitlab触发Jenkins的构建需要依赖Gitlab插件，而并不需要插件当中列出来的所谓的gitlab hook。如果直接在Jenkins当中安装插件失败，可以在国内镜像站下载对应插件，然后手动上传安装。

地址：清华大学开源软件镜像站。

安装之后，在构建触发器里边选中如下配置：

选中之后，会给到一个url地址，就是gitlab触发的回调地址，正常情况下，我们还会点开高级，生成一个匹配的token，用于安全方面的保障。

接着就是在gitlab对应项目中，创建一个回调的配置：

这里的配置，参考一张以前配置过的图片：

如果是首次添加，现在新版本的Gitlab可能会失败，报错 Urlis blocked: Requests to the local network are not allowed，需要选中如下：

添加之后，可以点击一下test看看流程是否能够走通，如果走通，那么我们以后开发的时候直接推送代码即可触发构建。

2，流水线中使用。

而今统一使用流水线之后，可以直接在Jenkinsfile当中进行配置，而不需要再重复如上步骤的操作了，当我们在Jenkinsfile中可以定义之后，也就意味着，以后如果新增一个项目，那么我们需要操作的步骤可能只有如下三步：

• 1，创建Jenkinsfile，放入到项目根目录中。
• 2，创建Jenkins项目，将项目URL写入到配置中。
• 3，将项目回调地址写入到Gitlab钩子当中。

仅需这么三步，一个全新的项目就配置完成了，极大的简化了运维的工作内容。

那么流水线的文件内容如下：

1. pipeline {
2. agent any
3. environment {
4. remote_ip = "192.168.3.66"
5. remote_dir = "/opt/hello"
6. }
7. triggers{
8. gitlab( triggerOnPush: true,
9. triggerOnMergeRequest: true,
10. branchFilterType: 'All',
11. secretToken: "${env.git_token}")
12. }
13. options {
14. buildDiscarder(logRotator(numToKeepStr: '10'))
15. disableConcurrentBuilds()
16. timeout(time: 10, unit: 'MINUTES')
17. timestamps()
18. }
19. stages {
20. stage('部署到测试环境'){
21. steps{
22. sh '''
23. rsync -avz --progress -e 'ssh -p 22' --exclude='Jenkinsfile' --exclude='.git' --delete ${WORKSPACE}/ root@$remote_ip:$remote_dir
24. '''
25. }
26. }
27. stage('delete') {
28. steps {
29. echo '清理工作目录'
30. cleanWs()
31. }
32. }
33. }
34. post {
35. success {
36. sh "echo 成功了"
37. }
38. failure {
39. sh "echo 失败了"
40. }
41. }
42. }

这里通过triggers的参数即可配置，其中的token我已经在Jenkins配置当中添加为全局变量，这样以来，所有的项目用同一个token即可：

当我们写完这个Jenkinsfile，执行上边我说的三步工作，直接把文件放到代码根目录，然后创建Jenkins项目，Gitlab配置回调地址，第一次先手动构建一下，以后再有相关push事件，就可以自动触发构建了。