gpt4 book ai didi

azure-devops - 为 PR 触发构建,但在 PR 完成之前阻止 CD

转载 作者:行者123 更新时间:2023-12-04 04:23:22 25 4
gpt4 key购买 nike

我和我的团队正在努力在 ADO 中实现特定的 CI/CD 模式。

我们定义了一个名为“Develop”的构建管道和一个同名的发布管道。我们在我们的开发分支上设置了一个构建策略,要求“开发”构建管道在 PR 完成之前成功。我们还制定了审核/批准、评论解决和链接工作项的政策。

正如预期的那样,当提出 PR 时,我们的政策中引用的构建就会启动。同样正如预期的那样,在构建成功之前无法完成 PR。然而,我们遇到的问题是,因为我们在发布管道上设置了一个 CD 触发器,无论其余 PR 策略的状态如何,由 PR 触发的构建生成的工件总是会被部署。

我们想要的顺序是这样的:

  • 提出 PR 会导致我们的“开发”构建管道执行。
  • 此构建必须成功才能完成 PR。
  • 这个构建的工件被存储,这样构建管道在 PR 完成后不必再次运行,只需进行部署(构建需要一段时间)。
  • 构建管道成功执行。
  • 在满足其他政策之前,PR 仍然无法完成。
  • 满足其余分支策略。
  • 公关完成。
  • 只有现在才能部署从构建管道生成的工件。
  • 执行“开发”发布管道,将工件部署到我们的测试环境。

  • 在摆弄了我们管道的变体之后,我尝试在发布管道上简单地设置“拉取请求触发器”而不是“持续部署触发器”。我认为这需要 PR 导致创建工件, 公关完成。我的假设是不正确的。使用这个新设置,提升 PR 会触发构建管道,构建管道的成功触发发布管道,即使 PR 尚未完成。

    我们的 Build Pipeline 构建解决方案、运行测试、运行一些 PowerShell 脚本,最后将工件发布到 Azure Pipelines。也许这样做太过分了。也许有某种方法可以构建、运行测试和脚本,然后以某种方式等待 PR 完成,然后再将工件传递到发布管道。我似乎无法弄清楚。有没有办法完成我上面列出的顺序?

    要求,简而言之:
  • 构建应该在 PR 提出后立即开始。
  • 构建不应执行多次(这需要很长时间,而且我们不能等待两次构建只是为了在“真正的”构建之前满足构建策略)。
  • PR 完成应触发发布管道。
  • 最佳答案

    从你的描述来看,对 PR trigger 有一些误解。

    You can configure a pull request trigger that will create a new release when a pull request uploads a new version of the artifact. Enable the trigger and add the branches targeted by pull requests that you want to activate this trigger.

    Pull request triggers



    但是对于 CD 触发器,您可以 添加构建分支过滤器 如果您只想在通过编译来自某些分支的代码生成构建时(仅适用于代码位于 TFVC、Git 或 GitHub 存储库中)或构建具有特定标签时创建发布。这些可以是包含和排除过滤器。例如,使用 features/* 将所有构建包含在 features 分支下。您还可以在过滤器值中包含自定义变量。

    或者,您可以指定过滤器以使用构建管道中指定的默认分支。 例如,当默认构建分支在每个开发冲刺中发生变化时,这很有用。这意味着您不需要为每次更改更新所有发布管道中的触发器过滤器 - 而是您只需更改构建管道中的默认分支。

    更多细节请看Jeff Shepler在这个类似问题中的回复: VSTS release pull request build trigger

    关于azure-devops - 为 PR 触发构建,但在 PR 完成之前阻止 CD,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/58549847/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com