在另一个工作流成功运行后手动触发 Github Actions 工作流

Posted

技术标签:

【中文标题】在另一个工作流成功运行后手动触发 Github Actions 工作流【英文标题】:Manually trigger Github Actions workflow after another workflow successfully runs 【发布时间】:2022-01-10 18:07:15 【问题描述】:

我正在尝试创建执行以下操作的 CI:

    运行 terraform plan -out=plan.out 以生成 Terraform 计划。 查看 Github 操作中的 Terraform 计划输出后,我可以手动使用之前生成的计划运行另一个调用 terraform apply plan.out 的作业或工作流。我想在其他自动化成功运行后手动运行此自动化,这取决于之前自动化的成功,使用来自之前自动化的工件。

我在网上查找了一些这样的例子,但我能找到的所有例子都只是运行terraform apply,而实际上不允许有人验证计划输出。

这在 Github Actions 中可以做到吗?

【问题讨论】:

是的,这是可能的,而且人们必须已经这样做了……这将使用拉取请求 (PR) 流程来完成……在 PR 创建时,您运行自动化测试并执行terraform plan ... PR 需要手动批准和合并 ... 然后合并触发 terraform apply ___ 我只是感觉你没有做 PRs @HelderSepulveda 我的计划是在合并到 master 后手动触发 terraform plan 作业。我的问题是我不知道如何构建工作流以便能够手动触发terraform apply terraform plan 成功运行之后。我不想在计划之后自动运行应用程序。我希望在计划之后进行人工干预。 @taleodor 我不确定那篇文章中有什么可以帮助我解决我的情况。 你在使用拉取请求吗? ...因为这是完全按照您的要求进行操作的正确方法 【参考方案1】:

这可以使用受保护环境的所需审阅者来完成:https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#required-reviewers

你要做的是设置一个环境,例如production 并将自己添加为审阅者。

在您的工作流程中,您可以像这样添加环境:

jobs:
  plan:
    steps:
      - run: terraform plan
  apply:
    environment: production
    steps:
      - run: terraform apply

这意味着一旦工作流到达作业apply,它就会停止,您需要手动单击按钮进行批准。

【讨论】:

我会将此标记为答案,但我使用的是私有存储库并且没有 Github Enterprise。不过还是谢谢你的回答。【参考方案2】:

我的解决方案最终如下:

当 PR 被批准和合并时,会创建一个 Terraform 计划并将其推送到 S3 存储桶,路径中包含提交哈希。然后,当通过工作流分派触发应用工作流时,它会查找正在运行的代码的提交哈希的计划并应用它。

按照建议使用拉取请求对我来说不是正确的解决方案,原因如下:

    您如何知道为拉取请求运行的计划是在基础分支上使用最新更改运行的?在这种情况下,该计划可能无效。我解决这个问题的方法是让计划工作流在推送与被 Terraformed 环境相对应的特定分支时运行。这样,计划总是针对 Terraform 所说的特定环境应该处于的状态生成。

    您如何知道申请正在应用为拉取请求生成的确切计划?我看到的所有示例实际上最终都在应用工作流中重新运行了计划,这破坏了 Terraform 计划的预期用途。我解决这个问题的方法是让应用工作流在云存储中查找特定的提交哈希。

【讨论】:

以上是关于在另一个工作流成功运行后手动触发 Github Actions 工作流的主要内容,如果未能解决你的问题,请参考以下文章

在另一个作业中重用 GitHub Action 工作流程步骤

TFS 2017:仅允许在发布到 DEV 和 QA 后手动部署到 PROD 环境

完成表中的数据插入后如何触发触发器

Socket.io - 客户端断开连接后手动重新连接

Eclipse中避免修改后台代码后手动install和重启

我应该在获取后手动关闭数据库连接和语句的游标吗?