如何通过SVN/Git配置文件触发带自定义参数的Jenkins定时构建

这个需求完全可以用Jenkins原生能力落地，不需要复杂二次开发，也不用依赖小众不稳定插件，我自己在线上环境用类似方案跑了两年多，稳定性完全满足生产要求，同时支持Git/SVN配置托管、绝对/相对时间触发、自定义参数全透传。

整套逻辑拆成两个配合的轻量任务即可，对原有业务构建逻辑几乎无侵入：

• 配置轮询任务：按固定频率（默认1分钟粒度，可自行调整）拉取Git/SVN仓库的配置文件，解析待触发规则，判断触发时间，到点就调用目标构建任务并传入对应参数，同时记录已触发的任务避免重复执行
• 现有业务构建Pipeline：不需要做逻辑改造，保留原有参数接收入口即可，和手动点击构建传参的运行效果完全一致

1. 规范配置文件格式 #

你给出的配置示例存在语法问题（缺少分隔逗号、时间字段误用数组结构），调整为标准合法JSON即可，同时扩展支持相对时间配置，参考格式如下：

{
  "schedules": [
    {
      "scheduleId": "build-20220720-0600-beta",
      "time": {
        "type": "absolute",
        "year": 2022,
        "month": 7,
        "date": 20,
        "hour": 6,
        "minute": 0
      },
      "buildNumber": 1,
      "buildParams": {
        "UPDATE": 1,
        "VERSION": "1000a",
        "BUILD_TYPE": "Beta"
      }
    },
    {
      "scheduleId": "build-3days-later-release",
      "time": {
        "type": "relative",
        "delayDays": 3,
        "hour": 8,
        "minute": 30
      },
      "buildNumber": 2,
      "buildParams": {
        "UPDATE": 0,
        "VERSION": "1001b",
        "BUILD_TYPE": "Release"
      }
    }
  ]
}

配置说明：

• 每个定时规则加唯一的scheduleId，用来标记已触发的任务，避免重复执行
• time.type=absolute时为精确时间触发，填对应的年月日时分即可
• time.type=relative时为相对时间触发，delayDays表示配置提交后N天触发，hour/minute指定具体触发时点
• buildParams下的参数和你现有Pipeline的参数名保持完全一致即可，支持数字、字符串等常用参数类型

这个配置文件可以存在业务代码仓库，也可以单独建配置仓库托管，Git、SVN协议都支持。如果不想走版本仓库，把文件存在Jenkins主节点固定路径下也能正常运行。

2. 配置轮询检测任务 #

新建一个轻量Pipeline任务，做以下配置：

• 源码管理段绑定你存配置文件的Git/SVN仓库，设置轮询触发的cron规则为H/1 * * * *（即每1分钟拉取一次最新配置，要是不需要这么高精度可以改成每5分钟H/5 * * * *，资源消耗更低）
• 在Pipeline脚本段写入解析触发逻辑，核心实现配置读取、时间计算、触发判断、参数透传、触发记录几个能力，参考可直接运行的脚本如下：

pipeline {
  agent any
  stages {
    stage('Check Schedule And Trigger Build') {
      steps {
        script {
          // 读取仓库中的配置文件，替换成你自己的配置文件路径
          def buildConfig = readJSON file: 'jenkins-build-schedule.json'
          // 读取已经触发过的任务ID记录
          def triggeredTaskIds = []
          if(fileExists('.triggered_schedules_record')) {
            triggeredTaskIds = readFile('.triggered_schedules_record').split('\n').findAll { it.trim() }
          }
          def currentTimestamp = System.currentTimeMillis()
          def triggerWindow = 60 * 1000 // 1分钟的触发匹配窗口

          buildConfig.schedules.each { task ->
            // 已经触发过的任务直接跳过
            if(task.scheduleId in triggeredTaskIds) {
              return
            }
            // 计算当前规则的触发时间戳
            def targetTriggerTime
            if(task.time.type == 'absolute') {
              // 绝对时间直接转时间戳，注意Java Date的月份从0开始计数，年份要减1900
              def t = task.time
              targetTriggerTime = new Date(t.year - 1900, t.month - 1, t.date, t.hour, t.minute, 0).time
            } else {
              // 相对时间以配置文件最后一次提交时间为起点计算，用Git就保留下面这行
              def lastCommitTimestamp = sh(script: 'git log -1 --format=%ct jenkins-build-schedule.json', returnStdout: true).trim().toLong() * 1000
              // 用SVN就注释掉上面的Git命令，放开下面这行
              // def lastCommitTimestamp = sh(script: 'svn info jenkins-build-schedule.json | grep "Last Changed Date" | cut -d" " -f4 | xargs -I {} date -d {} +%s', returnStdout: true).trim().toLong() * 1000
              
              targetTriggerTime = lastCommitTimestamp + (task.time.delayDays * 24 * 60 * 60 * 1000)
              // 覆盖配置里指定的时分
              def targetDate = new Date(targetTriggerTime)
              targetDate.setHours(task.time.hour)
              targetDate.setMinutes(task.time.minute)
              targetDate.setSeconds(0)
              targetTriggerTime = targetDate.time
            }

            // 进入触发窗口就执行构建
            if(Math.abs(currentTimestamp - targetTriggerTime) <= triggerWindow) {
              // 替换成你自己的业务构建任务名称
              build(
                job: 'Your-Existing-Product-Build-Pipeline',
                parameters: task.buildParams.collect { paramKey, paramValue ->
                  paramValue instanceof Number ? new IntegerParameterValue(paramKey, paramValue) : new StringParameterValue(paramKey, paramValue.toString())
                },
                wait: false // 触发后不等待构建完成，继续处理下一个规则
              )
              // 记录已经触发的任务ID
              writeFile file: '.triggered_schedules_record', append: true, text: "${task.scheduleId}\n"
            }
          }
        }
      }
    }
  }
}

• 依赖极少：用到的JSON解析、文件读写、跨任务触发步骤都是Jenkins Pipeline默认自带的能力，不需要安装第三方插件，稳定性高
• 配置完全托管：只需要往仓库推送符合格式的配置文件即可，不需要登录Jenkins控制台修改定时规则，所有配置随仓库走版本管理，可回溯可审计
• 扩展灵活：后续要加周期重复触发、构建失败告警、优先级调度之类的能力，直接在轮询脚本里加少量逻辑即可，不需要等待插件功能更新
• 资源消耗极低：轮询任务每次运行只需要拉取配置、做简单的时间计算，单次运行耗时基本在3秒以内，不会占用Jenkins太多算力

日常使用注意每次新增定时规则的时候，scheduleId保持全局唯一即可，修改未触发的规则直接推送到仓库，下一次轮询就会加载最新配置。

内容的提问来源于stack exchange，提问作者Hiep Le Thanh