定时流水线是什么
按 cron 计划触发的流水线：夜间全量回归、依赖更新巡检、安全扫描、环境清理，把长耗时与非紧急任务移出提交路径，让白天的反馈保持快速。定时任务无人盯守，失败必须接通知渠道，否则等于没跑。触发时通常还会注入自定义变量（如 NIGHTLY=true）供脚本区分运行来源。
基本信息
| GitLab | Pipeline schedules 页面配置 cron 语法与目标分支 |
|---|---|
| GitHub | on: schedule 使用 POSIX cron，UTC 时区，跑默认分支 |
| Jenkins | triggers { cron('H 2 * * 1-5') } 用 H 分散高峰 |
| 时间基准 | 各平台时区不同，换算本地时间要小心 |
| 失败处理 | 接入通知渠道并保留运行记录 |
典型使用场景
- 夜间全量回归：长时间集成测试放在低峰执行。
- 依赖巡检：定期检查过期依赖与安全公告。
- 安全扫描：低频但耗时的深度扫描任务。
- 清理维护：定时清理构建产物、缓存与临时环境。
- 报表生成：每日质量与流量报告定时产出。
- 环境巡检：定期检查证书有效期与域名解析。
GitHub Actions
GitHub Actions
on:
schedule:
- cron: '0 18 * * 1-5' # UTC 时间
jobs:
nightly:
runs-on: ubuntu-latest
steps: [{run: ./ci/nightly.sh}]平台对照
| 平台 | 配置位置 | 时间与分支 |
|---|---|---|
| GitLab | Pipeline schedules | 按平台时区，需指定目标分支 |
| GitHub | workflow 的 on.schedule | UTC，只统计默认分支 |
| Jenkins | cron 触发器 | 按服务器时区，H 分散执行 |
GitHub 定时任务在默认分支上运行且时间为 UTC；执行高峰可能出现延迟，关键任务要容忍晚跑。
把失败送进通知渠道：无人值守的任务出问题没人知道，等于没有这条流水线。
给定时运行传标记变量：脚本按 NIGHTLY 之类的变量调整范围，平时只跑冒烟集。
运行记录要保留：定时任务的日志与历史结果至少留存一个周期，用于判断这次失败是偶发还是趋势。
巡检频率与资产变化速度匹配：过高产生噪声，过低漏掉窗口，先定目标再定周期。