调用Jenkins REST API删除构建成功，为何仍提示认证要求？

这是个挺有意思的现象，我之前处理Jenkins脚本时也碰到过类似情况！核心原因和Jenkins的doDelete端点处理逻辑以及Invoke-WebRequest的默认行为有关：

问题根源拆解 #

1. Jenkins的删除流程：当你调用/doDelete端点时，Jenkins会先执行构建删除操作，完成后立刻返回一个3xx重定向响应（通常是跳转到项目的构建列表页面）。
2. Invoke-WebRequest的自动重定向：PowerShell的Invoke-WebRequest默认会自动跟随重定向，但在跳转后的请求中，很容易出现两个问题：
   • 重定向后的URL路径可能发生变化，导致会话中的认证信息或crumb没有被正确携带；
   • 跳转后的项目页面需要完整的认证上下文，但重定向请求没有重新获取有效的认证凭证，因此触发了"Authentication required"错误。
3. 关键结论：删除操作在重定向之前就已经成功完成了，所以你能看到构建被删掉，但后续的重定向请求失败抛出了错误。

解决办法 #

方法1：禁止自动跟随重定向 #

直接让Invoke-WebRequest不处理重定向，只关注删除请求的原始响应。修改后的代码如下：

Invoke-WebRequest "http://$serverhost/$projectUrl/$i/doDelete" -WebSession $session -Method Post -Headers $headers -MaximumRedirection 0

此时脚本会返回3xx状态码（比如302），这恰好是删除成功的信号，不会再触发后续的认证错误。

方法2：捕获并过滤重定向类错误 #

用try/catch块捕获异常，只处理真正的删除失败情况，忽略重定向导致的认证报错：

try {
    Invoke-WebRequest "http://$serverhost/$projectUrl/$i/doDelete" -WebSession $session -Method Post -Headers $headers
} catch [Microsoft.PowerShell.Commands.WebCmdletWebResponseException] {
    # 忽略重定向类的3xx状态码异常
    if ($_.Exception.Response.StatusCode -ge 300 -and $_.Exception.Response.StatusCode -lt 400) {
        # 可选：验证构建是否真的被删除
        $buildCheck = $null
        try {
            $buildCheck = Invoke-RestMethod "http://$serverhost/$projectUrl/$i/api/json" -Headers $headers -WebSession $session
        } catch {
            Write-Host "Build $i deleted successfully"
        }
        if ($buildCheck) {
            Write-Error "Build $i still exists - deletion may have failed"
        }
    } else {
        # 非重定向错误，正常抛出
        throw $_
    }
}

方法3：使用更简洁的REST API端点 #

如果你的Jenkins版本支持，推荐使用/delete专用端点，它不会触发重定向，返回的状态码更清晰（比如204表示删除成功）：

Invoke-RestMethod "http://$serverhost/$projectUrl/$i/delete" -Headers $headers -WebSession $session -Method Post

内容的提问来源于stack exchange，提问作者Zac Albert Carrell