4. Jenkins Pipeline深度：Pipeline语法详解与触发器配置

Pipeline，说白了就是Jenkins的灵魂。没有Pipeline的Jenkins，就像没有方向盘的汽车——能动，但很难控制方向。今天咱们就深入聊聊Pipeline的核心语法，以及怎么让它自动跑起来。

4.1 Pipeline核心语法：从stage到agent

先说说Pipeline的基本骨架。我个人习惯把Pipeline想象成一条生产线，每个stage就是一个工位，step就是工位上的具体操作。

4.1.1 stage与step：流水线的骨架

stage是逻辑上的阶段划分，step是具体的执行步骤。看个最简单的例子：

pipeline {
    agent any
    stages {
        stage('代码检出') {
            steps {
                echo '正在拉取代码...'
                checkout scm
            }
        }
        stage('编译打包') {
            steps {
                echo '开始编译...'
                sh 'mvn clean package'
            }
        }
        stage('单元测试') {
            steps {
                echo '执行测试...'
                sh 'mvn test'
            }
        }
    }
}

嗯，这里要注意：stage的名字要起得有意义。我在项目中遇到过有人把所有stage都叫"build"，结果出问题排查起来特别痛苦。你想想看，日志里全是"build"、"build"、"build"，鬼知道哪个是哪个。

4.1.2 agent：你的代码跑在哪里

agent指定Pipeline在哪个节点上执行。说白了就是告诉Jenkins："嘿，这段代码该在哪台机器上跑。"

agent类型	说明	适用场景
agent any	任意可用节点	简单任务，不依赖特定环境
agent none	全局不指定，每个stage单独设置	复杂流水线，不同阶段需要不同环境
agent { label 'docker' }	指定标签的节点	需要特定工具或环境的任务
agent { docker 'maven:3.8.1' }	在Docker容器中执行	环境隔离，避免"在我机器上能跑"的问题

我曾经踩过一个坑：全局用了agent any，结果某个stage需要JDK 11，但跑到的节点只有JDK 8。后来我改成每个stage单独指定agent，问题就解决了。

4.1.3 environment：环境变量的正确姿势

环境变量这东西，用好了事半功倍，用不好就是灾难。我建议把敏感信息和配置参数都放在environment块里管理。

pipeline {
    agent any
    environment {
        APP_NAME = 'my-app'
        VERSION = '1.0.0'
        // 敏感信息从Jenkins凭据中获取
        DOCKER_REGISTRY = credentials('docker-registry-cred')
    }
    stages {
        stage('构建镜像') {
            steps {
                sh """
                    docker build -t ${DOCKER_REGISTRY}/${APP_NAME}:${VERSION} .
                """
            }
        }
    }
}

4.2 参数化构建：让流水线活起来

参数化构建，说白了就是让用户在点击"构建"时能输入一些参数。我经常用它来做版本发布——输入版本号、选择发布环境，一键搞定。

pipeline {
    agent any
    parameters {
        string(name: 'BRANCH', defaultValue: 'main', description: '要构建的分支')
        choice(name: 'ENV', choices: ['dev', 'staging', 'prod'], description: '部署环境')
        booleanParam(name: 'RUN_TESTS', defaultValue: true, description: '是否运行测试')
    }
    stages {
        stage('参数校验') {
            steps {
                echo "构建分支: ${params.BRANCH}"
                echo "部署环境: ${params.ENV}"
                echo "运行测试: ${params.RUN_TESTS}"
            }
        }
    }
}

为什么要有参数校验？我在项目中遇到过有人不小心把prod环境选成了dev分支的代码，差点酿成生产事故。从那以后，我每个参数化构建都会加一个校验stage。

4.3 触发器：让流水线自动跑起来

手动构建太累了，咱们得让流水线学会自己跑。Jenkins提供了三种主流触发方式。

4.3.1 Webhook触发：代码一推，构建就跑

这是最常用的方式。开发人员push代码到GitHub/GitLab，自动触发构建。配置起来很简单：

pipeline {
    agent any
    triggers {
        // GitHub Webhook
        githubPush()
        // 或者更通用的方式
        pollSCM('* * * * *')
    }
    stages {
        stage('构建') {
            steps {
                echo '代码有更新，开始构建...'
            }
        }
    }
}

4.3.2 定时触发：像闹钟一样准时

有些任务需要定时执行，比如每天凌晨跑一次全量测试。用cron语法配置：

pipeline {
    agent any
    triggers {
        // 每天凌晨2点执行
        cron('0 2 * * *')
        // 周一到周五，每30分钟执行一次
        cron('*/30 * * * 1-5')
    }
    stages {
        stage('定时任务') {
            steps {
                echo '定时构建执行中...'
            }
        }
    }
}

cron语法看着复杂，其实记住几个常用模式就够了。我一般用在线cron生成器，省得自己算。

4.3.3 Poll SCM：定期检查代码变化

Poll SCM是Webhook的备选方案。它定期去代码仓库检查有没有新提交，有就触发构建。

pipeline {
    agent any
    triggers {
        // 每5分钟检查一次代码变化
        pollSCM('*/5 * * * *')
    }
    stages {
        stage('检查更新') {
            steps {
                echo '检查代码更新...'
            }
        }
    }
}

4.4 知识体系总览

说了这么多，咱们用一张图来总结Pipeline的核心知识体系：

这张图把Pipeline的核心要素都串起来了。语法是骨架，参数化是灵活性，触发器是自动化。三者缺一不可。

好了，Pipeline的核心语法和触发器配置就聊到这儿。记住一点：好的Pipeline设计，能让你的CI/CD流程像流水线一样顺畅。多花点时间在设计上，后面运维会轻松很多。

---

公众号:蓝海资料掘金营，微信deep3321