GitLab 合并请求 API + merge_status

如何解决GitLab 合并请求 API + merge_status

我们正在尝试使用 GitLab API 根据 Jira 票证的移动自动执行合并请求生命周期。

使用 /merge_requests 端点，我可以看到 merge_status 字段似乎包含以下值之一：unchecked、can_be_merged、cannot_be_merged、 cannot_be_merged_recheck 或 checking。

问题 1：是否有任何文档说明各个状态值的含义，以及什么会触发这些值返回？

我还可以看到控制 with_merge_status_recheck 字段更新/报告方式的 merge_status [option]https://docs.gitlab.com/ee/api/merge_requests.html)（在 13.0 中添加）的使用。

API 文档说明：

• Introduced 在 GitLab 12.8 中，当对此端点发出请求时，会异步检查每个合并请求的可合并性 ( merge_status )。轮询此 API 端点以获取更新状态。这会影响 has_conflicts 属性，因为它依赖于 merge_status 。它返回 false 除非 merge_status 是 cannot_be_merged 。
• Introduced 在 GitLab 13.0 中，列出合并请求可能不会主动更新 merge_status（这也会影响 has_conflicts），因为这可能是一项昂贵的操作。如果您需要来自此端点的这些字段的值，请在查询中将 with_merge_status_recheck 参数设置为 true。

并且参数选项说：

with_merge_status_recheck -- 如果 true ，此投影请求（但不保证）异步重新计算 merge_status 字段。默认为 false .

问题 2：如果我调用 GET https://gitlab.com/api/v4/projects/:project_id/merge_requests/:id?with_merge_status_recheck=true，预期的结果是什么？参数文档说明with_merge_status_recheck发起了异步计算，但是我怎么知道merge_status的值什么时候准确，我可以依赖呢？

我已尝试使用 with_merge_status_recheck=true 和 =false 对调用进行计时，并且没有明显的性能偏差可以表明发生了什么。