我选择了Kdawg的答案，因为它帮助我找到了我需要的方向。谢谢!

我还附上了我自己的答案，因为我实现的解决方案与Kdawg的答案不同，我觉得它会为其他人增加价值。

首先，我是新来的Jenkins。因此，如果我说错了，请随时纠正我。其次，我有一个轻微的学习曲线，因为Jenkins的“队列项”和Jenkins的“构建作业”是不同的。一旦创建了“队列项”，就没有“生成作业”ID，因为还没有启动生成作业。此外，一旦生成作业启动，队列项在被删除之前有5分钟的时间。

当我执行这些任务时：

curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass

Jenkins将调度3个构建作业在队列中运行。这些将是“排队项”。这些“队列项”将有一个“队列ID”。在我的原始问题中给出的示例中，假设这三个cURL命令使用“Queue ID”的121、122和123创建“Queue Items”。

为什么这很重要？

因为根据Jenkins服务器的负载，排队的项目可能会立即运行，也可能不会立即运行。如果它立即运行，那么Kdawg的答案肯定是正确的。运行他的命令：

curl -X GET http://jenkins_srv:8080/queue/item/121/api/json?pretty=true --user name:pass
curl -X GET http://jenkins_srv:8080/queue/item/122/api/json?pretty=true --user name:pass
curl -X GET http://jenkins_srv:8080/queue/item/123/api/json?pretty=true --user name:pass

这将获得有关每个“队列项”的队列信息，如果构建作业已经启动，那么在返回的内容中，肯定有一种方法可以获得“构建作业”ID。如果生成作业尚未启动，则此信息将为空。

我觉得，这是增加价值的额外部分。

一旦构建作业启动，Kdawg答案中的信息将被填充到对三个curl -X GET命令的响应中。此外，默认情况下，Jenkins被设计为每5分钟清理(垃圾收集，选择您自己的术语)“队列项”。因此，换句话说，如果您所拥有的只是一个“队列项”ID，并且5分钟的数据保留窗口过去了，那么您需要另一个机制来从“队列项”ID获取“构建作业”ID。

因此，在我的例子中，我使用Jenkins作为前端，Ansible作为后端来执行服务器配置和应用程序部署。其中一些应用程序部署可能需要30分钟或更长时间，远远超过“队列项”的5分钟数据保留期。

因此，我必须解决的问题是，如果我所拥有的只是一个“队列项”ID，那么我如何找到一个“构建作业”ID，无论我何时检查、几秒钟后还是几小时后？

以下是我的解决方案(请注意，我需要XML输出，仅供参考)。

我运行了这个命令：

curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass

此命令将返回以下信息：

Runtime responseHeaders Date: Day, ## Non Year xx:yy:zz GMT
X-Content-Type-Options: nosniff
Location: http://jenkins_srv:port/queue/item/123/
Content-Length: 0
Server: Jetty(9.4.z-SNAPSHOT)

从这里，我可以从Location字段中解析出123。

然后我睡了10秒钟。在休眠之后，我在10秒的循环中运行以下命令：

curl -X GET http://jenkins_srv:8080/queue/item/123/api/xml

我一直这样做，直到我：

1.我得到了一个队列项返回，其中包含Kdawg的示例中所示的XPath//Executable/Numbers，或者
1.我收到了超过10分钟的HTML404状态代码，这意味着作业尚未排队，或者我超过了5分钟的数据保留窗口。

以这种方式运行的循环处理的Jenkins服务器负担过重，处理队列请求的速度很慢。因此，假设我在10分钟结束时，我的方法仍将处理这样的用例，即我的自动化方法已成功排队并运行作业，但它正在检查数据保留窗口外的Jenkins。在本例中，我将运行以下命令：

curl -X GET http://jenkins_srv:port/job/MY_JOB/api/xml?tree=builds[id,number,result,queueId]&xpath=//build[queueId=123]

这将返回还包含123的queueId的任何“构建作业”的XML信息，如下所示：

<?xml version="1.0"?>
    <build _class="hudson.model.FreeStyleBuild">
        <id>456</id>
        <number>456</number>
        <queueId>123</queueId>
        <result>SUCCESS</result>
    </build>

通过这种方式，我能够权威地获得“构建作业”ID，而只拥有一个“队列项”ID，而不管我开始和检查回来时之间的时间差。

假设您有一个位置http://jenkins_srv:8080/queue/item/123/，您可以使用GET http://jenkins_srv:8080/queue/item/123/api/json?pretty=true返回有关该队列项的信息(如果您不关心格式化，也可以不包含?pretty=true，或者如果您希望以XML格式显示结果，则可以使用api/xml)。

我不知道是否有关于队列API的标准文档，但看起来队列项是否已经完成(可能还在构建中？)它将有一个executable节点。我的服务器的一个示例如下所示：

"executable" : {
    "_class" : "org.jenkinsci.plugins.workflow.job.WorkflowRun",
    "number" : 10,
    "url" : "http://192.168.99.100:32769/job/configure/10/"
}

然后可以GET在executable.url中指定的URL的API。在我的例子中，是GET http://192.168.99.100:32769/job/configure/10/api/json?pretty=true。从那里，您应该有了所需的所有信息，包括当前是否正在构建构建、构建花费了多长时间、结果等。

此外，如果您想要有关整个构建队列的信息，您可以GET http://jenkins_srv:8080/queue/api/json?pretty=true

令人惊讶的是，Jenkins没有使用唯一的ID跟踪请求直到得出结论。

在排队项和生成项之间持续存在的一个元素是参数列表。如果您有能力/权限更改作业的配置，则添加一个可选参数REQUEST_ID，客户端从空中获取该参数(例如UUID)并通过REST传递。然后，您可以询问队列并查找具有您的REQUEST_ID的队列，并且您可以询问构建列表并查找具有您的REQUEST_ID的队列。

有趣的是，如果您想要在循环中对多个构建进行排队，最终可能会得到相同的QUEUE_ID，尤其是当您具有相同的参数并且排队的构建尚未启动时会发生这种情况。基本上，Jenkins假设您只是尝试构建此作业，而不是多个构建，它只假设它只需要启动单个构建，因此使用相同的QUEUE_ID来克服这一问题。如果您在构建作业时添加了额外的参数，如UQ_ID=CURRENT_TIMESTAMP(此参数不需要在BUILD中)，那么您将获得唯一的内部版本号

如果构建中根本没有参数，您应该至少定义一个参数，因为无参数的构建不允许在API中传递任何参数

您可以通过id获取作业详细信息

Http://localhost:8080/job/{jobName{/{jobId}/api/json

curl --location --request GET 'http://localhost:8080/job/testPipeline/2/api/json' 
--header 'Authorization: Basic 1234'