Documentation
¶
Overview ¶
Package catalog loads and validates the usecase catalog embedded in the binary (catalog.yml): the server's well-known bundles, grouped into usecases a client sets up with one call, dependencies included.
A usecase is a set of bundles installed together plus the usecases it requires; every bundle is one created root under a permanent `system:<name>/v<n>` id, declaring a type objects carry, a miniapp the client opens, records on the root, or several of those. Client contract: docs/28-well-known-bundles.md.
Validation here is structural and pure — ids, handles, the dependency graph, relation links, module rules — and collects every problem rather than the first, with its yaml path. What needs the server's descriptor gate (slug against kind, option shapes, miniapp values) is layered on top by the server package; both run at boot, in `make test` and in `make catalog-validate`.
Index ¶
Constants ¶
const ( CodeBadYAML = "catalog.bad_yaml" CodeUnknownField = "catalog.unknown_field" CodeBadId = "catalog.bad_id" CodeDuplicate = "catalog.duplicate" CodeMissing = "catalog.missing" CodeBadField = "catalog.bad_field" CodeUnknownUsecase = "catalog.unknown_usecase" CodeCycle = "catalog.cycle" CodeBrokenLink = "catalog.broken_link" CodeBadMiniapp = "catalog.bad_miniapp" )
Problem codes.
const BundleIdPattern = "system:<name>/v<n>"
BundleIdPattern is the grammar of a catalog bundle id, for messages.
Variables ¶
This section is empty.
Functions ¶
func Load ¶
Load decodes a catalog and runs the pure validation, returning every finding. The catalog is nil only when the source did not decode; with structural problems it is still returned, so a caller layering more checks on top can report everything in one pass — but Get and Order are trustworthy only when Problems is empty.
Types ¶
type Catalog ¶
type Catalog struct {
Usecases []api.CatalogUsecase
// contains filtered or unexported fields
}
Catalog is a loaded, structurally valid catalog.
func (*Catalog) Get ¶
func (c *Catalog) Get(id string) (api.CatalogUsecase, bool)
Get returns the usecase with the id.
func (*Catalog) Order ¶
func (c *Catalog) Order(id string) ([]api.CatalogUsecase, bool)
Order returns the usecase's transitive dependency closure in setup order — dependencies first, each once, the requested usecase last. Deterministic: requires are walked in declaration order.
func (*Catalog) SupersedeGroup ¶ added in v0.2.2
func (c *Catalog) SupersedeGroup(bundleId string) *SupersedeGroup
SupersedeGroup returns the group the bundle belongs to, nil when no `supersedes` edge touches it.
func (*Catalog) Superseded ¶ added in v0.2.2
Superseded reports whether another bundle of the catalog supersedes the one with this id: it is kept where a space already has it and never what a new space receives.
type Options ¶
type Options struct {
// KnownTypeIds are the registered (built-in) type and collection
// ids of the server: reserved against catalog xKeys, and valid
// relation targets. `any`, `type` and `collection` are always
// included.
KnownTypeIds []string
// RootTypeIds are the registered type ids a bare bundle root may
// name as its `rootType`.
RootTypeIds []string
}
Options tune the pure validation with what only the server knows.
type Problem ¶
type Problem struct {
// Path is the yaml path of the offending node
// (`usecases[3].bundles[1].type.properties[2].xFormat`).
Path string
Code string
Message string
}
Problem is one validation finding: where, what, why.
type Problems ¶
type Problems []Problem
Problems is the error a validation returns — every problem found, in document order.
type SupersedeGroup ¶ added in v0.2.2
SupersedeGroup is one connected set of bundles linked by `supersedes`: the superseded ones (Old) and the ones standing in for them (New), each in declaration order. A space is on the group's old shape while any bundle of Old is installed — it then walks Old and never receives New — and on the new shape otherwise. One group per component, so a bundle superseded by two others and a bundle superseding two others pull all of them into one decision.
Source Files
Directories
¶
| Path | Synopsis |
|---|---|
|
cmd
|
|
|
catalog-validate
command
catalog-validate checks the usecase catalog embedded in the binary and any candidate files given as arguments, printing one line per problem (`<source>: <path>: <code>: <message>`) and exiting 1 on any.
|
catalog-validate checks the usecase catalog embedded in the binary and any candidate files given as arguments, printing one line per problem (`<source>: <path>: <code>: <message>`) and exiting 1 on any. |