我已经设置了用于部署 Firebase Web 应用的 Cloud Build 管道。
问题
当前脚本执行不必要的部署。即使后端文件没有更改，它最终也会测试和部署后端(需要 3 分钟；后端测试需要 4 分钟)。
前端也是如此(构建和部署只需约 30 秒)。
上下文
GitHub/Cloud Build 集成有效，以便在合并 PR 后通知 Cloud Build。没关系。
我可以创建两个单独的 CI 作业，并按更改的文件进行过滤(这在 Cloud Build 控制台中可用)。这里的问题是，如果两者在同一次提交中发生更改，我希望首先部署后端。
Come to think of it, I can bypass this by giving development guidance: if there are breaking changes (eg. a data model changes in the backend, or a new service such as Cloud Storage is added), those changes need to be deployed first in the backend. Making eg. two commits or deploying the backend manually.
你会做什么？
我认为上述的侧面想法就是我的前进方向。
如果您有 Cloud Build 经验，您如何处理此类情况？
链接已更改为编写问题时的代码。
添加了 22 年 7 月:我最终按照引用部分中的想法做了:对“后端发生变化”、“前端发生变化”有单独的触发器。他们可以自由竞争谁先部署；如果它成为一个问题，引用的手动过程将起作用。
最佳答案
如果 CI 作业之间存在依赖关系，则需要使它们相互依赖。在您的情况下，您有 2 个独立的触发器:两个触发器都在同一事件上触发，但每个触发器都有自己的管道和文件过滤。因此，两者都可以并行执行，并且它们不依赖。
解决方案是使作业相互依赖:开始一项作业，然后开始下一项作业。在您的情况下，您可以在 Github 事件上触发后端管道。最后(如果有东西要构建或没有)，您需要触发前端管道。
您有几种解决方案:
- PubSub 消息
- GCloud CLI
- WebHook
此解决方案的主要权衡是顺序性。如果你必须 build 背面和正面，则需要 4 分钟 + 3 分钟。
关于firebase - 云构建 : How to execute two CI jobs, 顺序如何？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/68496730/