构建触发与调度

Jenkins 的构建触发方式决定"什么时候跑流水线"。选错触发方式会造成重复构建、错过构建或资源浪费。

本篇目标：能配置 Webhook 实时触发、Poll SCM 轮询、定时构建和流水线级联触发，并理解各方式的取舍。

1. 触发方式总览

方式	实时性	是否需仓库配合	适用
Webhook（推荐）	实时	需在仓库配置回调	代码提交、MR 事件
Poll SCM（轮询）	有延迟（分钟级）	无需仓库配置	仓库不支持 Webhook、内网隔离
定时构建（Cron）	按计划	无需	周期任务、每日构建、巡检
参数化 / API 触发	手动或程序触发	可选	运维操作、其他系统调用
流水线级联（build 步骤）	实时	无需	Job 间依赖、上下游

优先 Webhook

Webhook 提交即触发，是 CI 的标准方式。Poll SCM 会定时访问仓库，有延迟且频繁轮询对仓库有压力，仅在不得已时用。

2. Webhook 实时触发

2.1 GitLab 示例

在 Jenkins 的 Job 配置中勾选 Build Triggers → Build when a change is pushed to GitLab；
配置 GitLab 插件生成的 Webhook URL：

http://ci.company.com/project/<project-name>

在 GitLab 仓库：Settings → Webhooks → 添加上述 URL，触发事件勾选 Push events、Merge request events、Tag push events。

2.2 Gitea / GitHub

平台	插件	Webhook 事件
GitLab	GitLab	Push / MR / Tag
Gitea	Gitea	Push / Pull Request / Release
GitHub	GitHub	Push / Pull Request / Release

2.3 Webhook 排障

现象	检查
Webhook 未触发	仓库 Webhook 配置、网络连通、Jenkins 地址可达
401/403	Webhook Token / 认证没对上
触发了但 Job 没跑	多分支的分支过滤、Job 的触发配置
内网无法回调	用 Poll SCM 或在内网部署反代转发

3. Poll SCM

Build Triggers → Poll SCM
Schedule: H/5 * * * *        # 每 5 分钟检查一次

Cron 语法与系统 cron 类似，但用 H 做哈希分布避免同一时刻全部扫描：

表达式	含义
`H/5 * * * *`	每 5 分钟
`H H(0-6) * * *`	每天凌晨
`H(0-59)/15 * * * *`	每 15 分钟
`@daily` / `@weekly`	每天 / 每周

Poll SCM 只在新提交时触发

Poll SCM 会先做一次 git 远端比对，有变化才触发构建，不是"每 5 分钟构建一次"。频繁提交会被合并成一次构建。

4. 定时构建

Build Triggers → Build periodically
Schedule: H 2 * * *          # 每天 02:00

与 Poll SCM 的区别：Build periodically 到点就构建，不管有没有新提交。适用于：

每日全量构建 / 打包基线；
定时测试（如凌晨跑全量集成测试）；
巡检类 Job（定时检查证书、清理过期分支）。

时间要避免整点风暴

多个 Job 都配 0 2 * * * 会在同一秒全部触发，Master 瞬时压力大。用 H 2 * * * 让 Jenkins 在每个 Job 间错开。需要精确时间时才写具体分钟（如 15 2 * * *）。

5. 参数化 / API 触发

# 触发带参数构建
curl -X POST "$JENKINS_URL/job/$JOB/buildWithParameters" \
  --user "$USER:$API_TOKEN" \
  --data "ENV=prod&IMAGE_TAG=v1.2.3"

# 触发不带参数构建
curl -X POST "$JENKINS_URL/job/$JOB/build" \
  --user "$USER:$API_TOKEN"

用 API Token 而不是密码（见第 4 篇）。

6. 流水线级联（build 步骤）

Job 之间的上下游依赖，用 build 步骤触发：

stage('部署后端') {
    steps {
        build job: 'deploy/backend', parameters: [
            string(name: 'IMAGE_TAG', value: "v${BUILD_NUMBER}")
        ], wait: true, propagate: true
    }
}

参数	含义
`wait: true`	等待下游构建结束
`wait: false`	异步触发，不等待
`propagate: true`	下游失败则上游失败
`propagate: false`	下游失败不影响上游

// 并发触发多个下游，全部完成后继续
stage('并行发布多服务') {
    steps {
        script {
            ['service-a', 'service-b', 'service-c'].each { svc ->
                build job: "deploy/${svc}", wait: false
            }
        }
    }
}

避免循环触发

A 触发 B、B 又触发 A 会形成无限循环。用触发器配置的"禁止重复构建"（disableConcurrentBuilds）或给级联构建加防护条件（如检查参数来源）。

7. 触发选择决策

需要什么触发？
├── 代码/MR 变更即构建 → Webhook（推荐）或 Poll SCM
├── 每天/每周固定任务 → 定时构建（Build periodically）
├── 手动/外部系统触发 → 参数化 + API
├── Job 上下游依赖 → build 步骤级联

生产常见组合：Webhook 实时触发 + 每日定时全量构建兜底 + 部署 Job 用 build 级联。

8. 练习与验收

练习 A

为多分支流水线配置 GitLab/Gitea Webhook，push 代码确认实时触发
配一个 H/5 * * * * 的 Poll SCM Job，验证行为
配一个每日 02:00 的定时构建 Job

练习 B

用 curl + API Token 触发一个带参数的 Job
写两个 Job：上游触发下游（build job: ..., wait: true），验证 propagate
体验 disableConcurrentBuilds 防止重复触发

验收清单

理解 Webhook、Poll SCM、定时、API、级联五种触发方式
能配置 GitLab/Gitea/GitHub 的 Webhook
会用 Cron（含 H 分散）配置定时构建
会用 build 步骤做 Job 级联，理解 wait/propagate
知道避免触发循环和整点风暴

下一篇：与 Kubernetes 集成。

1. 触发方式总览​

2. Webhook 实时触发​

2.1 GitLab 示例​

2.2 Gitea / GitHub​

2.3 Webhook 排障​

3. Poll SCM​

4. 定时构建​

5. 参数化 / API 触发​

6. 流水线级联（build 步骤）​

7. 触发选择决策​

8. 练习与验收​