​
Configs

Applications have a variety of configurations serving different purposes. Below are some configs for a fictional robot. Each config is responsible for a particular aspect of the robot’s behavior.

Every config has a history of config schemas and a history of concrete configs deployed to robots. Below are the config schemas for the Motion Control config.

​
Config Schemas

Miru requires the use of config schemas. These schemas validate concrete configs before deployment, preventing runtime application errors.

Config schemas live in your git repository (preferably in the same repository as the code consuming the config) to minimize versioning errors between code and configurations.

As an example, let’s say our application has the following directory structure.

src/...
configs/
├── motion-control-config.yaml
└── ...
config-schemas/
├── motion-control-schema.yaml
└── ...

The motion-control-config.yaml file defines concrete config values for development use only. As a developer, quickly defining and editing configurations in your local development environment is essential.

The motion-control-config.yaml file serves this purpose exactly. The file will not be uploaded to the cloud or used to deploy concrete configs to your production robots. It is strictly for local development purposes.

The motion-control-schema.yaml file defines the schema for the concrete motion-control-config.yaml config, specifying the constraints on the parameters it can instantiate.

​
Local Development

Miru provides an SDK for deploying configs, which pulls concrete configs from the cloud. Here’s a sample code snippet of the SDK in action.

motion_control_config = client.get_config(
    slug="motion-control-config",
    schema_file="./config-schemas/motion-control-schema.yaml",
)

However, it’s critical that the SDK allows for quick changes to concrete config values in development. The SDK accepts a boolean argument to determine whether it should fetch a concrete config from a file on the local file system (development) or from the cloud (production).

motion_control_config = client.get_config(
    # ... other parameters that don't matter for development
    development_file="./configs/motion-control-config.yaml",
    development=true,
)

In development, the SDK will use the motion-control-config.yaml file defined locally. In production, the SDK will pull the concrete config from the cloud.

​
Uploading a Config Schema

Once ready to deploy new configurations, config schemas are uploaded to the cloud using the Miru CLI.

miru upload \
--config-slug="motion-control-config" \
--config-schema-path="./configs/motion-control-schema.yaml"

The miru upload command collects some git information to help you version and track config schemas when viewing them in the Miru dashboard. Miru does not have access to your git repository. The git information is extracted from the git repository where the miru upload command is run from.

$ miru upload --config-slug="motion-control-config" --config-schema-path="./configs/motion-control-schema.yaml"

🚀 Attempting to upload schema ./configs/motion-control-schema.yaml for config motion-control-config...

Git Information:
commit: 8f4d2e1
origin: git@github.com:miru/config-service.git
branch: origin/main

✅ Successfully uploaded schema for config motion-control-config
Schema is now available for use in production deployments.

After executing miru upload, config schemas are available in the Miru dashboard.

We recommend using the miru upload command in your CI pipeline to upload your config schemas automatically. Miru will know if a config schema has changed and will not create a new config schema if it has already been uploaded in a previous commit.