如何利用Python实现对Jenkins流水线的自动化触发与状态监控？-Python教程-PHP中文网

应选 buildwithparameters；因含 parameters 的流水线若用 build 会返回 400 错误，必须用 buildwithparameters 并通过 location 响应头获取 queue item 再查 executable.number 得真实构建号，同时需处理 crumb token、并发归属及轮询判断 building==false 而非 result。

如何利用python实现对jenkins流水线的自动化触发与状态监控？

触发Jenkins流水线时，`buildWithParameters` 和 `build` 怎么选？

直接调用 /job/{job_name}/build 只能触发无参构建；如果流水线定义了 parameters（比如 stringParam name: 'VERSION'），必须用 buildWithParameters，否则 Jenkins 返回 400 错误且不执行。

实操建议：

先访问 http://jenkins-url/job/{job_name}/api/json?tree=parameterDefinitions[name,type,defaultValue] 确认参数结构
POST 请求地址为 http://jenkins-url/job/{job_name}/buildWithParameters，参数以 form-data 或 query string 方式传入（推荐 query string，避免 Content-Type 冲突）
若使用 requests.post()，别加 json=... —— Jenkins 不接受 JSON body，只认 URL 参数或 x-www-form-urlencoded
记得带上 token（在 job 配置页生成）或 API Token + 用户凭证，否则返回 401 或 403

获取构建号（`build_number`）不能依赖响应体

Jenkins 的 build 或 buildWithParameters 接口默认返回空响应（HTTP 201），不会直接告诉你本次构建是 #42。想拿到刚触发的 build_number，得靠 Location 响应头。

实操建议：

检查响应头中的 Location 字段，例如 http://jenkins-url/queue/item/123/
再 GET 这个 queue item 地址，解析 JSON 中的 executable.number 字段 —— 它才是真实构建号
如果 executable 为 null，说明还在排队，需轮询（建议间隔 1–2 秒，最多重试 10 次）
别用 lastBuild.number 取号：并发触发时会拿错

监控构建状态时，`result` 字段为空代表还在运行

GET http://jenkins-url/job/{job_name}/{build_number}/api/json?tree=result,timestamp,building,duration 是最轻量的轮询方式。但要注意：result 字段只有构建结束才非空（如 "SUCCESS"、"FAILURE"）；运行中它就是 null，而 building 为 true。

python-code-analyz

专业Python代码分析与优化，支持语法检查、安全扫描、性能评估、复杂度分析及重构后优化代码生成。

下载

实操建议：

判断完成的唯一可靠依据是 building == false，不是 result != null
轮询间隔别太密（建议 ≥2s），否则压垮 Jenkins API（尤其启用了 CSRF protection 时）
超时控制必须有：比如 30 分钟没结束就主动标记为 TIMEOUT，避免脚本卡死
如果需要日志流，用 /job/{job_name}/{build_number}/logText/progressiveText?start=0，注意它返回的是增量文本，需记录 start 偏移

Python 脚本里处理 Jenkins 的 CSRF token（`crumb`）容易漏掉

开启 Prevent Cross Site Request Forgery exploits 后，所有 POST/PUT/DELETE 请求必须带 crumb 头，否则 403。这个 token 本身要先 GET 获取，且有有效期（默认 5 分钟）。

实操建议：

首次请求前，先 GET http://jenkins-url/crumbIssuer/api/json，提取 crumb 和 crumbRequestField
把 {crumbRequestField}: {crumb} 加进后续每个 POST 请求的 headers 里
不要复用旧 crumb：如果轮询持续时间长，中途 crumb 过期会导致后续构建失败，建议每 3 分钟刷新一次
用 requests.Session() 自动携带 Cookie，避免登录态丢失

真正麻烦的不是写几行代码，而是 crumb 有效期、queue item 的延迟、以及并发下 build_number 的归属判断 —— 这三处出问题，监控脚本就会“以为成功”或“永远等不到结果”。