Skip to content

deploy

Deploy a project by triggering its workflow_dispatch GitHub Actions workflow.

Usage

subscribed deploy                                   # fully interactive
subscribed deploy <project>                         # skip project selection
subscribed deploy <project> --env <environment>     # skip environment selection
subscribed deploy <project> --ref <branch>          # skip branch selection
subscribed deploy <project> --ref main --env production  # non-interactive

Flow

When arguments are omitted, the CLI prompts interactively:

  1. Project — select from the list (skipped if passed as argument)
  2. Environment — select from the project's configured environments
  3. Branch — fetched live from GitHub; list is filtered to main/master only when deploying to production
  4. Confirm — shows a summary before triggering

Projects

Key Name Repo Environments
bkdk Barberklingen DK subscribed-aps/barberklingen-dk-bedrock develop, master
bkse Barberklingen SE subscribed-aps/barberklingen-se-bedrock develop, master
bknl Barberklingen NL subscribed-aps/barberklingen-nl-bedrock develop, master
kddk Kaffedrengen DK subscribed-aps/kaffedrengen-dk-bedrock develop, master
elome-bedrock Elome - Bedrock subscribed-aps/elome-com-bedrock develop, master
elome-nuxt Elome - NUXT subscribed-aps/elome-com-nuxt development, production

Production guardrail

Deployments to the production environment are restricted to the main or master branch. This is enforced in two ways:

  • Interactive — the branch list is filtered to only show main/master
  • Non-interactive — passing --ref feature/x --env production exits with an error

Which environment counts as "production" is configured per project via productionEnvironment in src/lib/projects.ts.

Adding a project

See development docs.

Requirements

  • subscribed auth login must have been run with a token that has repo and workflow scopes
  • The target workflow must have workflow_dispatch enabled