过了 schema 不等于就有效

一句话总结

目录分为结构和政策两层。只有通过结构的实体只是形式正确，即使名字中有空格spec用乙写成大太郎也可以进去。

##为什么要看两层呢

在前面的模块中写了多个catalog-info.yaml。但是，那个练习的地方没有Backstage后端，所以没有办法确认那个YAML是否真的通过。

这个练习不会全部打开Backstage——需要数百MB和几分钟的构建时间。而是直接运行将要放入目录中的直接的库。

结构和政策抓取不同的东西

目录分为两层。```text 스키마 형태 — apiVersion·kind·필수 필드가 있는가 정책 규칙 — 이름 형식, 63자 제한, 모르는 루트 필드 거부

`entitySchemaValidator`只要输入就会只看到结构体。所以即使名字有空格，`spec`乙`spce`即使写错了也能通过。真正的目录上面覆盖着**政策**。

阻止不知道的根字段的原因特别珍贵。`spce`如果错误通过，该服务就会**没有spec**——没有owner也没有lifecycle——进入目录。就像剪下CNPA的结构模式一样。

## 引用会建立关系`owner: team-a`其实`group:default/team-a`是指向的参考。这些参考聚集在一起成为图表，Backstage屏幕上的“谁拥有什么并依赖什么”就是这些图表绘制的结果。如果参考被破坏，关系就会断开——这就是为什么名称格式很严格。

## 设置以键为单位深度合并

最后一个文件并不覆盖全部。字符串的后面会赢，只在一边的键会生存下来，**数组会全部替换**。这个数组规则是陷阱。

## 在哪里进行验证？

什么时候知道目录拒绝**决定**开发者经验。即使是相同的错误，根据注意到错误的时机，成本也会完全不同。

- **在编辑器中** — 将模式连接到IDE后，一旦字段名称写错，就会画下划线。最便宜。

- **在CI** — 到仓库`catalog-info.yaml`如果这个变了，就会进行验证。因为合并之前会被阻止，所以错误的东西根本不会进来。

- **目录收集时** — 已经合并后失败，这一事实只留在门户网站的日志中，没有人看到。

大部分组织只有第三个，这就是列表安静地变旧的原因。**将验证转移到CI所需的成本几乎为零。**将与本练习中使用的库命名为脚本，如果失败，用终止代码通知即可结束。然后，该脚本必须一起放入新的存储库模板中，以后生成的存储库也会自动跟随。

##目录腐烂的方式

开发者门户网站失败的原因不是功能不足，而是**列表与现实不同**。没有人相信的列表没有人看到，不看的列表更快变旧。这种恶性循环的开始地点被确定在几个地方。

**指拥有者为空或消失的团队。**如果有组织重组，组名会变更，但实体会保持不变。断开参考的实体会在屏幕上漂浮着关系断开的状态，在出现故障时无法知道应该联系谁。**定期统计没有拥有者的实体并以此为指标**是最便宜的防御。

**即使服务消失，项目也会留下。**即使删除存储库，如果目录中还有最后一次阅读的内容，就不存在的服务也会继续出现在列表中。如果原件消失，也要掌握收集方式，使项目也消失，手动注册的项目在这一点上尤其不受影响。

**只注册，没有人打开。** 目录只有在其中包含实际需要的项目时才有价值。仪表板、接线员、最近发布、文档。如果没有这种连接，目录就只是一个写着名称和所有者的表格。

因此，成熟的团队将**目录作为检查对象。**定期检查是否填写了必填字段，是否是所有者存在的组，是否在指定生命周期值的列表中，以及在创建新存储库时模板是否正确。`catalog-info.yaml`一起放入。如果人们每次都用手写的话，形式就会各不相同，如果差别的积累，就无法用列表来统计什么了。

## 在实际工作中真正重要的东西

**必须开启拒绝未知根目录字段的政策。**`spec`乙`spce`如果写错的错误通过的话，该服务会在没有owner或lifecycle的情况下进入目录。虽然注册成功了，但如果owner为空，就会堆积起空项，这是列表腐烂最常见的途径。

**参考格式严格的原因是它是一个关系图。**`owner: team-a`是`group:default/team-a`是指向的参考，屏幕上的“谁拥有什么并依赖什么”都是根据这个图表绘制的结果。如果参考被破坏，关系就会全部中断。

**在设置合并中，数组会全部更换。**标量是后面的胜出的，只有一边有的键会生存下来，但数组的规则不一样。如果把数组一半写在每个环境的文件中，前面的文件中的项目都会全部消失。

在下次实习中，这些真的被直接拒绝为实际的图书馆，进行确认。