Taiga

曾经有过相同的思路对成都航空（没办法中文客服放了几十分钟音乐）。
但是对方听到我要用中文就挂了。。。
没办法又只能重新播回去用英文和他们唠了很久。

这项目 nice 啊，start 了

验货宝真心坑。
之前卖 mbp 系统给你搞坏，搞不转了就给你退回来。

看了下之前创建的 key ，好像默认就是禁用计费的项目下的。
文档： https://cloud.google.com/billing/docs/how-to/modify-project#disable_billing_for_a_project

@IronCore864 这么问是因为我觉得 DevStream 的定位有点奇怪。从他上面可以看到 Terraform 的影子，并且也提出了 DevOps toolchain as code 的点子。

但是我能想到的使用场景，也就在新起项目的时候快速 copy 出一条标准化的模板。之后的修大概率不会再用 DevStream 了。
因为像 pipeline 本来就是 code 了，没必要再 as code 一次。仓库 /看板（ SaaS ）配置本来就是一次性配置，不会频繁修改没有 as code 的必要。

至于 SSoT ，为了实现他而产生的 double 学习 /配置成本，我个人会觉得不是特别划得来。

简单的看了下，如果有理解错误 po 主请纠正我。
所以解决的痛点是，打通 DevOps 工具链，把一个比较通用解决方案给到项目上。
那么之后呢。比如说，action 运行了一段时间 pipeline 需要修改，是改 stream 配置重新部署，还是直接去仓库把 aciton 改了？

我还是喜欢战地 2142