经过进一步的调查,我想出了一个解决方案,看起来效果很好:
我发现,即使您没有使用“/builds/?locator=buildType:x”调用获得有关自定义构建属性的任何信息,您也可以提取该列表中每个构建的构建 ID,然后执行以下操作:另一个 REST 调用以获取有关某个特定构建的更多详细信息。其余的调用如下所示:
http://teamcity/httpAuth/app/rest/builds/id:{0}
此调用的响应将为您提供一个“构建对象”,其中包含构建属性列表等。
我跟踪构建进度的解决方案是这样的:
将构建添加到 TeamCity 队列时,我首先向 URL 添加一个名为“BuildIdentifier”的属性。该值只是一个 GUID。我将此标识符传递回客户端应用程序,然后客户端开始轮询服务器,询问具有此特定标识符的构建的状态。然后,服务器会执行一些步骤来识别构建的当前阶段:
1:检查构建是否正在运行。我通过调用“/builds?locator=running:true”获取正在运行的构建的列表,迭代构建并使用构建 ID 查询 REST API 以获取详细信息。然后,我检查每个正在运行的构建的详细信息,寻找具有与我从客户端收到的属性相匹配的“BuildIdentifier”属性的构建。如果正在运行的构建之一存在匹配项,我会向正在跟踪进度的客户端发送一条响应,其中包含一条消息,表明构建正在以 x%(构建对象的 PercentageComplete 属性)运行。如果未找到匹配项,我将继续执行步骤 2。
2:检查是否完成:首先使用“/builds/?locator=buildType:x”调用获取最新的构建列表。然后执行与步骤 1 相同的操作,并从列表中提取 X 个最新版本(我选择了 5)。为了限制 REST 调用的数量,我假设构建将在最新的 5 个构建中(如果完成)。然后,我在 BuildIdentifier 上查找匹配项,如果找到匹配项,我将返回构建的状态(失败、成功等)。
3:如果步骤 1 或 2 中的 BuildIdentifier 不匹配,我可以假设构建位于队列中,因此我将其作为当前状态返回。
在客户端,只要状态表明构建在队列中或正在运行,我就会每隔 x 秒轮询一次服务器的状态。
如果其他人也遇到同样的问题,希望这个解决方案能够有所帮助!我认为,如果您使用 TeamCity REST API,那么跟踪触发构建的进度是一项非常常见的任务。