自动构建的原始配置以及pipeline中的用法

文章发布较早，内容可能过时，阅读注意甄别。

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

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

# 1，传统方式。

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

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

地址：清华大学开源软件镜像站。 (opens new window)

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

选中之后，会给到一个 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 钩子当中。

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

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

pipeline {
    agent any
    environment {
        remote_ip = "192.168.3.66"
        remote_dir = "/opt/hello"
    }
    triggers{
        gitlab( triggerOnPush: true,
                triggerOnMergeRequest: true,
                branchFilterType: 'All',
                secretToken: "${env.git_token}")
    }
    options {
        buildDiscarder(logRotator(numToKeepStr: '10'))
        disableConcurrentBuilds()
        timeout(time: 10, unit: 'MINUTES')
        timestamps()
    }
    stages {
        stage('部署到测试环境'){
            steps{
                sh '''
                    rsync -avz --progress -e 'ssh -p 22' --exclude='Jenkinsfile' --exclude='.git' --delete ${WORKSPACE}/  root@$remote_ip:$remote_dir
                '''
            }
        }
        stage('delete') {
            steps {
                echo '清理工作目录'
                cleanWs()
            }
        }
    }
    post {
        success {
            sh "echo 成功了"
        }
        failure {
            sh "echo 失败了"
        }
    }
}