合并 PR 后如何限制 Azure DevOps YAML 管道中的关联工作项?

Posted

技术标签:

【中文标题】合并 PR 后如何限制 Azure DevOps YAML 管道中的关联工作项?【英文标题】:How to limit associated work items in Azure DevOps YAML pipeline once PR is merged? 【发布时间】:2021-03-11 13:53:03 【问题描述】:

我一直在将 Azure DevOps 中的构建/发布管道迁移到统一的 YAML 格式。一旦 PR 合并到主分支,除了与 CI 构建相关的工作项之外,一切都按预期工作。这是工作流程:

    开发人员提出 PR 以将功能分支中的更改合并到主分支中 PR 具有针对测试环境执行 YAML 管道的构建策略 PR完成,将feature分支合并到master分支中 YAML 管道有一个 CI 触发器,用于部署到更高的环境

对于第 2 步,触发的构建会显示与 PR 关联的任何工作项:

但是,对于第 4 步,触发的 CI 构建会列出主分支中的所有工作项,而不仅仅是与 PR 关联的那些:

有没有办法只将与 PR 关联的工作项关联到 CI 构建,一旦特性分支合并到 master 就会触发?

【问题讨论】:

Azure DevOps 应该自动将您的合并与 master 进行比较,并且只关联新添加的工作项。听起来你可能失去了一个共同的祖先。当你合并到 master 时,你执行的是哪种类型的合并? 我们正在使用合并(没有快进)。此合并策略在旧的构建和发布管道中按预期工作;发布管道与预期的工作项相关联。 嗯,那真的很奇怪。这应该工作得很好。 【参考方案1】:

我可以重现这个问题,我找到了一个类似的票,他们已经报告了,你可以关注这个ticket以获取最新消息。

如果构建状态是队列或运行,那么我们创建一个新构建,新构建将包含构建之前的链接工作项。这就是为什么第 4 步触发的 CI 构建列出了 master 分支中的所有工作项,而不仅仅是与 PR 关联的那些。

如果所有构建都完成,那么我们完成拉取请求以触发 CI 构建,它将与预期的工作项相关联。

当所有构建完成后,我合并 PR 以触发 CI 构建,它只包含拉取请求链接工作项。

测试结果

【讨论】:

感谢您的复制。你是说这是预期的设计吗? IE。 (主)CI 构建的链接工作项显示尚未发布的所有内容?如果这是真的,那么我不知道如何从我所处的情况中恢复过来。我最新的 CI 版本显示了 41 个链接的工作项,但是只有 ~5 个尚未部署到生产环境中...... 我创建了他提到的票。我录制了一个视频,准确显示链接的工作项错误的问题:knowledge.autodesk.com/community/screencast/… 我目前有一个解决方法,我只需获取我以前成功的构建,找到链接到它的 PR,然后从公关。遗憾的是,您无法为构建编辑已链接的工作项(至少不是我在 Devops RestAPI 中看到的)。我将它们分开保存并附加标签+更新“集成在构建中”字段,然后我将其用于发布说明。 嗨@RikDePeuter,这不是预期的设计,我们已经报告了这个问题,我们可以关注票以获取最新消息。另外,根据视频,您可以尝试在之前的所有构建完成后触发下一个 CI 构建或 PR 触发构建,然后它将与预期的工作项相关联。 我认为这是一个问题,我只是展示了链接预期工作项而不是链接所有工作项的解决方法。我也在关注ticket,如果有更新,我会在这里分享。

以上是关于合并 PR 后如何限制 Azure DevOps YAML 管道中的关联工作项?的主要内容,如果未能解决你的问题,请参考以下文章

如何在Azure DevOps中向管道中的远程分支发出拉取请求?

在 Azure Devops 上完成拉取请求后,如何自动“git tag -a”?

是否可以限制谁可以在 Azure DevOps 中完成拉取请求?

Azure DevOps 上的拉取请求以强制替换而不是合并

在 Azure DevOps 中对拉取请求运行选择性测试用例

如何在 Azure DevOps 中删除合并的功能分支?