关于CloudBees Jenkins Enterprise 2.249.2.4-rolling版本API删除项目的接口差异及curl调用方法咨询

现象解释 #

你遇到的这种情况其实是Jenkins API演进过程中的兼容性遗留问题：

• 早期Jenkins的操作API大量采用POST + doXXX的命名模式（比如doDelete），这是当时的设计习惯，把删除这类操作包装成表单提交的POST请求来实现。
• 后来Jenkins逐步向标准REST API规范靠拢，引入了符合HTTP语义的方法——用DELETE请求直接访问任务资源路径（/job/<MY_JOB>）来完成删除操作。

而你的CloudBees Jenkins Enterprise 2.249.2.4-rolling版本出现这种矛盾，大概率是这几个原因：

1. 版本兼容性保留：CloudBees定制版本为了兼容旧有脚本和集成逻辑，特意保留了doDelete的POST接口，但标准DELETE接口可能因为版本特定的bug、插件配置或者权限策略限制，导致无法正常工作。
2. CRSF保护拦截：Jenkins默认开启CRSF防护，标准DELETE请求如果没有正确携带CRSF Token，会被服务器直接拒绝；而旧的doDelete接口是基于表单提交的，通常可以通过附带表单里的crumb参数自动通过验证，所以能成功执行。
3. 请求配置遗漏：测试DELETE请求时，可能没设置正确的认证信息（比如Basic Auth头），或者Content-Type等请求头不符合Jenkins API的要求，导致请求被拦截。

curl调用方案 #

方案1：使用旧的doDelete POST接口（你当前可用的稳定方式） #

这个方式不需要处理复杂的CRSF验证（表单提交模式下默认兼容），直接用curl发送POST请求即可，记得替换<MY_SERVER>、<MY_JOB>、<USERNAME>和<API_TOKEN>：

curl -X POST "http://<MY_SERVER>/job/<MY_JOB>/doDelete" \
  -u "<USERNAME>:<API_TOKEN>"

如果你的Jenkins开启了严格的CRSF防护且需要显式传递crumb，先获取crumb再请求：

# 先获取CRSF crumb
CRUMB=$(curl -u "<USERNAME>:<API_TOKEN>" "http://<MY_SERVER>/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,\":\",//crumb)")

# 发送删除请求
curl -X POST "http://<MY_SERVER>/job/<MY_JOB>/doDelete" \
  -u "<USERNAME>:<API_TOKEN>" \
  -H "$CRUMB"

方案2：适配标准DELETE接口（如果想遵循新API规范） #

如果要让DELETE请求生效，需要确保携带正确的认证和CRSF Token，步骤如下：

# 1. 获取CRSF crumb
CRUMB=$(curl -u "<USERNAME>:<API_TOKEN>" "http://<MY_SERVER>/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,\":\",//crumb)")

# 2. 发送DELETE请求
curl -X DELETE "http://<MY_SERVER>/job/<MY_JOB>" \
  -u "<USERNAME>:<API_TOKEN>" \
  -H "$CRUMB"

如果还是失败，可以排查这几点：

• 你的账号是否拥有该任务的删除权限
• Jenkins全局安全配置中，是否对DELETE请求有额外的拦截规则
• 是否有权限管理类插件影响了REST API的访问

内容的提问来源于stack exchange，提问作者Matt Case