Define the schemas
Releases are defined by the config schemas they contain. The getting-started repository contains two sets of schemas for each of JSON Schema and CUE:- Empty schemas - regard all config instances as valid
- Strict schemas - constrain the valid fields, types, and values for instances of the config type they belong to
- JSON Schema
- CUE
Empty SchemasStrict Schemas
Schema annotations
Each of the above schema examples carries annotations — metadata that Miru uses to process the schema and deploy config instances to the correct location on the device. The config type is the only required annotation; the rest are described below.required
The config type is a required annotation that identifies the config type to which a schema belongs. Below is the syntax for annotating a schema with a config type slug.If the provided config type slug does not yet exist, it is automatically created. To edit a config type after creation, visit the config types documentation.Examples:
mobility, communication, perceptionThe schema language declares the language that a schema is written in. This annotation applies to Opaque schemas only, and is required for them.JSON Schema and CUE schemas have no schema language annotation. Their language is inferred from the schema file itself, so a Because an opaque schema is written as JSON or YAML — the same formats as a JSON Schema — this annotation is what distinguishes the two.
.cue file is read as CUE, and a .json or .yaml file is read as JSON Schema unless it declares itself opaque.Opaque
The instance file path is the absolute file system path where config instances for this schema are written on the device.This annotation is optional and defaults to Examples:
/srv/miru/configs/{config-type-slug}.{instance-format}. To share the same schema amongst multiple config instances, declare instance slots instead./srv/miru/configs/mobility.json/home/myapp/configs/communication.yaml/var/lib/myapp/configs/safety.yaml
Instance slots define one or more config instances that are valid for a given schema.
Instead of maintaining a near-identical config type for each destination, declare
several slots to allow multiple config instances to share a single schema.This annotation is optional. Omitting it will either use the instance file path annotation, or create a single slot with default values.For more information about instance slots, visit the Instance slots section of the schemas documentation.
The instance format declares the format that config instances for this schema are deployed as on the device.Visit the File formats section of the schemas documentation to learn which formats are supported for each schema language.This annotation is optional and is inferred from the instance file path’s extension. Under the default instance file path of Examples:
/srv/miru/configs/{config-type-slug}.json, the instance format therefore defaults to json.json, yaml, xml, textSet up the CLI
Next, we’ll install the CLI—the primary method of creating releases in Miru. Creating releases via the CLI is a deliberate design choice. We believe a release’s schemas should live in a Git repository. This allows them to be versioned alongside the code that uses them and encourages better software development practices. While this tutorial covers creating releases on your local machine, the CLI can also be used to create releases in a CI pipeline. Install The CLI is only available on macOS and Linux. Windows is not supported.- macOS
- Linux
Install via Homebrew.
If you are not seeing the latest CLI version, refresh Homebrew with
brew update.login command.
Create a release
With the CLI setup, we are ready to create a release in Miru. Navigate to the root of the getting-started repository and create the release with a schema set of your choice.- JSON Schema
- CUE
Git metadata is pulled from the local Git repository that the schemas are defined in.





