picto.yaml & Flavors

Stop passing --client-app-id/--owner-id/--api-key by hand — generate a picto.yaml once instead.

upload_assets (and any CLI command added later) needs --client-app-id/--owner-id/--api-key every time you run it. A picto.yaml file at your project's root lets you set those once instead of remembering — and copying — them from the dashboard on every call.

Generating one interactively#

dart run picto:setup

This signs in to your dashboard account, lists the organizations and client apps it owns, and lets you pick one (or create a new client app on the spot) — then writes the result into picto.yaml for you. Run it again to add another flavor (see below) to the same file; it won't disturb flavors you've already saved.

Already have real Android/iOS build flavors set up in your project? dart run picto:init detects them and creates a client app for every one in a single pass, instead of walking through this flow once per flavor.

The file itself#

defaultFlavor: "dev"
flavors:
  dev:
    clientAppId: "ca_..."
    ownerId: "us_..."
    apiKey: "oc_..."
  prod:
    clientAppId: "ca_..."
    ownerId: "us_..."
    apiKey: "oc_..."

Key	Meaning
`flavors`	One or more named entries, each a distinct `client_apps` row.
`defaultFlavor`	Which flavor to use when a command doesn't pass `--flavor` and the file declares more than one. Optional if there's only one flavor — it's used automatically.

An explicit --endpoint/--client-app-id/--owner-id/--api-key flag always overrides whatever picto.yaml would have supplied, so you can override just one value on a one-off run without touching the file.

Flavors#

A flavor is a name (e.g. dev, staging, prod) mapped to its own client app — the same isolation boundary the dashboard already uses, not a new concept. This keeps recordings and uploaded assets from different environments from landing in the same place: a dev build and a prod build point at two different client apps, so their recordings, assets, and dashboard views never mix.

Pick which flavor a command uses with --flavor:

dart run picto:upload_assets --flavor prod

If picto.yaml only declares one flavor, --flavor isn't needed — it's used automatically. If it declares more than one and neither --flavor nor defaultFlavor says which to use, the command fails fast with the list of flavor names it found, rather than guessing.

Asset uploads follow the same boundary as recordings: since an asset reference is looked up by (client_app_id, name), each flavor's asset bundle is uploaded (and resolved during replay) independently — run upload_assets --flavor <name> once per flavor whose assets have changed, not once for the whole project.