Variant-Specific Deploy Repositories

Each catalog variant of a project deploys into its own container repository, so several variants of one project can be deployed at the same time without their images overwriting each other. The repository a wbsp-app deploy writes is the same one the git-push path uses for that variant (wbsp-v-<short-uuid>-<image>).

Declaring the variant in wbsp.yaml

Add the variant's UUID:

name: my-app
variant: a1b2c3d4-0000-4000-8000-000000000000

Get the UUID with wbsp-app whoami, run inside the variant's git checkout:

wbsp-app whoami            # prints just the UUID (script-friendly)
wbsp-app whoami -v         # UUID + project, slug, and the variant's wbsp.ai URL

whoami resolves the variant from the repository's git remote via wbsp-api (authenticated). Populate the field in one step:

yq -i ".variant = \"$(wbsp-app whoami)\"" wbsp.yaml

Apps that are not catalog variants

Platform-internal or non-catalog apps opt out instead:

name: my-service
non_variant: true          # keeps the legacy wbsp-<name> repo

variant and non_variant are mutually exclusive.

What happens if you forget

On an aws deploy, a wbsp.yaml with neither field is rejected before anything is built or pushed:

Error: wbsp.yaml declares no variant for app "my-app". Run `wbsp-app whoami` to
get the variant UUID and add `variant: <uuid>` to wbsp.yaml (or set
`non_variant: true` for a non-catalog app ...).

This is deliberate — silently sharing one repository is what let variants clobber each other. dev destinations produce no image and are unaffected.

Scope

This applies to the AWS/ECR deploy path today. wbsp-app whoami needs the catalog's git→variant resolve endpoint to be live to resolve real variants.