Create - Miru

Create a release along with its associated git commit, config schemas, upload rules in Miru. For a more detailed guide on creating releases, visit the release creation guide. To include upload rules, see the release upload rules guide.

Requirements

Schemas and upload rules must be committed to a local Git repository
Schemas must be annotated with their config types (see annotations)
Git repository must have a remote URL (e.g. GitHub) configured
At least one config schema is provided (upload rules are optional)

API key scopes

If creating a release from a CI pipeline, the following API key scopes are required:

git_commits:manage
config_types:manage
config_schemas:manage
releases:manage

If creating a release with upload rules, the following API key scopes are also required:

upload_collections:manage
upload_rules:manage

Usage

Schema Directory
Schema Files
Upload Rules

Use the --schemas flag to specify a directory containing the schemas to include in the release.

miru release create \
  --version {version} \
  --schemas {/path/to/schemas/directory/}

Use the --schema flag to specify schema files to include in the release.

miru release create \
  --version {version} \
  --schema {path/to/schema1.yaml} \
  --schema {path/to/schema2.yaml}

Use the --upload-rule flag to include upload rule files in the release, or --upload-rules for a directory of rule files. Upload rules ride along with the release’s config schemas.

miru release create \
  --version {version} \
  --schemas {/path/to/schemas/directory/} \
  --upload-rule {path/to/rule1.yaml} \
  --upload-rules {/path/to/upload/rules/directory/}

Flags

string

required

A semantic version, unique for a given release.Versions must be dot-separated integers. You may optionally use a v prefix, a prerelease suffix (e.g. -alpha.X, -beta.X, -rc.X), or a build suffix (e.g. +build-metadata).Examples: v1, 1, v2.1, 2.1, v3.2.1, 3.2.1, v4.3.2-beta.1, 4.3.2-rc.1, v5.4.3+metadata, 6.5.4-beta.2+metadata

string

A directory containing the config schemas to include in the release. May be specified multiple times for multiple directories.Must be specified if no schema files are provided.Examples: ./schemas

string

The path to a config schema to include in the release. May be specified multiple times to include multiple schemas.Must be specified if no schema directory is provided.Examples: ./schemas/schema1.yaml, ./schemas/schema2.yaml

string

A directory containing upload rule YAML files to include in the release. May be specified multiple times for multiple directories. Only YAML files in the directory are picked up.Examples: ./upload-rules/

string

The path to an upload rule YAML file to include in the release. May be specified multiple times to include multiple rules.Examples: ./upload-rules/robot-logs.yaml

Examples

New Schemas
Existing Schemas

If the provided git commit and schemas do not exist in Miru, they are created and attached to the new release. This is indicated by the (new) suffix in the output.

command

$ miru release create \
  --version v1.0.0 \
  --schemas ./cue/strict-schemas/

◐ Creating release v1.0.0

  ✓ Pushed git commit (new)
    1c7f7a8 · mirurobotics/getting-started

  ◐ Pushing schemas
    ✓ Mobility · SCH-D5nFP (new)
    ✓ Planning · SCH-37QAr (new)
    ✓ Communication · SCH-9WfCx (new)

✓ Created release v1.0.0

If the provided git commit and schemas already exist in Miru, they are attached to the new release. This is indicated by the (existed) suffix in the output.

command

$ miru release create \
  --version v1.0.0 \
  --schemas ./cue/strict-schemas/

◐ Creating release v1.0.0

  ✓ Pushed git commit (existed)
    1c7f7a8 · mirurobotics/getting-started

  ◐ Pushing schemas
    ✓ Mobility · SCH-D5nFP (existed)
    ✓ Planning · SCH-37QAr (existed)
    ✓ Communication · SCH-9WfCx (existed)

✓ Created release v1.0.0

​Requirements

​API key scopes

​Usage

​Examples

Requirements

API key scopes

Usage

Examples