触发方式是什么
让代码推送触发构建有两条路径：代码平台侧 webhook 即时通知 Jenkins，或 Jenkins 定时轮询仓库兜底。webhook 快，但依赖网络可达与插件配置；轮询稳，但有延迟并产生持续拉取压力。内网 Jenkins 接不到外网 webhook 时，需要代理或中继把事件送进去。
基本信息
| webhook | GitLab/GitHub 插件接收推送事件直接触发 |
|---|---|
| 轮询 | triggers { pollSCM('H/5 * * * *') } |
| 兜底 | 双通道并存减少漏触发 |
| 网络 | 内网场景需要代理或中继 |
| 错峰 | H 前缀让不同任务分散拉取 |
| 诊断 | 在系统日志中对比两条通道的触发记录 |
| 可观测 | hook 投递记录与 Jenkins 触发日志对照排查 |
轮询兜底示例
轮询兜底示例
pipeline {
agent any
triggers {
pollSCM('H/5 * * * *') // 每约 5 分钟轮询一次，H 错峰
}
stages {
stage('build') { steps { sh 'make build' } } // 轮询触发后的构建
}
}典型使用场景
- 即时反馈：webhook 让推送后秒级开始构建
- 内网友好：轮询适配 Jenkins 无法被外网回调的场景
- 双保险：webhook 丢事件时轮询在下一周期补上
- 迁移过渡：从轮询迁移到 webhook 期间两者并行
- 多仓库任务：按仓库规模设置不同轮询间隔
- 排障：对比触发时间线判断是 hook 丢了还是轮询没跑
- 变更评审：把触发链路写进值班手册，按图排查
方式对比
| 方式 | 时效 | 成本与风险 |
|---|---|---|
| webhook | 秒级 | 依赖网络与插件，事件可能丢失 |
| 轮询 | 分钟级延迟 | 对仓库与 Jenkins 有持续压力 |
| 双通道 | 即时加兜底 | 配置略复杂，触发记录要能区分 |
| H 错峰 | 不改变时效 | 避免整点集中拉取 |
| 间隔调优 | 越短越接近实时 | 过密形成无谓压力 |
轮询表达式中的 H 用于错峰：避免整点集中拉取形成尖峰，多任务共存时尤其明显。
只配 webhook 无兜底：网络抖动导致漏触发，关键分支要加轮询兜底。
轮询间隔过密：对仓库与 Jenkins 双方都形成无谓压力，按团队节奏定间隔。
webhook 到 Jenkins 的链路要可观测：投递记录与触发日志对照，才能快速定位断点。