Watch the Catalog Actually Reject

This lab runs on the real Backstage libraries

The VM has Backstage's catalog and configuration libraries installed. If you put in a catalog-info.yaml, it is actually validated, wrong ones are rejected, and several app-config.yaml files are actually merged.

It does not bring up a whole Backstage instance — that takes hundreds of MB and several minutes of build. Instead it runs directly the very libraries used when putting things into the catalog. The validation, the merging, and the relation resolution are all real.

The catalog lab in the earlier module went only as far as practicing writing catalog-info.yaml. There was no way to check whether that YAML actually passes.

The first start takes about 4 minutes (npm install goes over the internet).

What is prepared

프로젝트    /opt/cba (Backstage 라이브러리 설치됨)
검증 도구   validate-entity <yaml파일>
라이브러리  /opt/cba/lib.js (catalog-model·config·yaml)

Steps

Create one entity, make it pass validation, and put it in /root/cba/entity.txt.
Put in /root/cba/reject.txt how a wrong entity is actually rejected.
Put in /root/cba/refs.txt how relations are resolved by entity references (parseEntityRef).
Connect eight kinds of entities by owner and system and put it in /root/cba/graph.txt.
Merge several app-config.yaml files and put in /root/cba/config.txt which one wins.
Put in /root/cba/env.txt how environment variable substitution (${...}) works.
Scan the whole catalog, diagnose its consistency, and put it in /root/cba/audit.txt.
In /root/cba/report.md, write the three lines valid=, rejected=yes, and merge_winner= along with an explanation.

Notes

Validate with validate-entity good.yaml. If it passes you get OK:, and if it fails you get REJECTED:.
Run scripts with node script.js, and use the library with require('/opt/cba/lib.js').
Common misconception: that if the schema passes it is valid. The policy (name format, root fields) filters out more.
Common misconception: that with configuration the last file overwrites everything. It is merged deeply, key by key.

An entity to put into the catalog

Create one entity, make it pass validation, and put it in /root/cba/entity.txt.

You need kind, metadata.name, and spec. A Component requires type, lifecycle, and owner.

The schema alone is not enough

Put in /root/cba/reject.txt how a wrong entity is actually rejected.

Try putting an uppercase letter or a space in the name, and try putting in an unknown root field. The schema and the policy each catch different things.

References create relations

Put in /root/cba/refs.txt how relations are resolved by entity references (parseEntityRef).

Resolve user:default/jdoe and team-a with parseEntityRef. See how the default kind and namespace are filled in.

Connect the eight kinds

Connect eight kinds of entities by owner and system and put it in /root/cba/graph.txt.

Create Component, API, Resource, System, Domain, Group, and User, and connect them with owner, system, and providesApis.

Configuration is merged deeply

Merge several app-config.yaml files and put in /root/cba/config.txt which one wins.

Layer several app-config files. The last file does not overwrite everything; they are merged key by key.

Environment variables in configuration

Put in /root/cba/env.txt how environment variable substitution (${...}) works.

${VAR} is substituted with the environment variable at load time. It is a way of not putting secrets in the file.

A catalog rots as time passes

Scan the whole catalog, diagnose its consistency, and put it in /root/cba/audit.txt.

Validate several entities at once, and count how many passed, were rejected, and had no owner.

What you learned

In /root/cba/report.md, write the three lines valid=, rejected=yes, and merge_winner= along with an explanation.

Write the three lines valid=, rejected=yes, and merge_winner= along with an explanation.