云构建:如何按照顺序执行两个CI作业？

Question

我已经设置了一个云构建管道，用于部署Firebase web应用程序。

• https://github.com/akauppi/GroundLevel-firebase-es/blob/eb312e11a8f7167b3d6becbf52d7013396cd53f2/ci/cloudbuild.merged.yaml

问题

当前脚本执行不必要的部署。即使后端文件没有更改，它也会以测试和部署后端结束(后端测试需要3分钟；4分钟)。

同样地，对于前端(只构建和部署30级)。

上下文

GitHub / Cloud集成工作，以便在PR已经合并之后通知云构建。这很好。

我可以做两个独立的CI作业，被修改的文件过滤(这在中可用)。这里的问题是，如果两者都在同一个提交中更改，我希望首先部署后端。

想起来了，我可以通过给出开发指导来绕过它:如果有突然的变化(例如。后端中的数据模型更改，或者添加了新的服务(如云存储)，需要首先在后端部署这些更改。制造(如)两次手动提交或部署后端。

你会怎么做？？

我想上面的想法就是我要去的地方。

如果您有云构建的经验，如何处理这种情况？

在编写问题时，链接更改为代码的形式。

增加了7月22日:我最终做了在引用部分的思考:有单独的触发器“事情在后端改变”，“事情改变在前端”。他们可以自由竞争谁首先部署；如果它成为一个问题，引用的手动过程将工作。

Answer 1

如果您的CI作业之间存在依赖关系，则需要使它们相互依赖。在您的例子中，您有两个独立的触发器:这两个触发器都是在同一个事件上触发的，但每个触发器都有自己的管道和文件筛选。因此，你和你都可以并行执行，而且它们不依赖。

解决方案是使作业依赖于:启动一个作业，然后启动下一个作业。在您的例子中，您可以在Github事件上触发后端管道。最后(如果需要构建或不需要构建)，您需要触发前端管道。

对此您有几种解决方案：

CLI

• WebHook

• PubSub message
• GCloud GCloud

这个解决方案的主要优点是顺序性。如果你必须建造后和前面，它将需要4分钟+3分钟。