deploylisted

# Deploy Ask every question in this skill with AskUserQuestion. Values: `BRANCH` = `git rev-parse --abbrev-ref HEAD`, `PROJECT` = the URL-encoded project path (`group%2Fsub%2Fproject`) derived from `git remote get-url origin`, needed only by the `glab api` calls. `glab ci` reads the project from the remote of the working directory; `-R group/sub/project` points it at another repository instead, which is how a rollout spanning several services runs without a single `cd`. `glab api` takes no `-R` — there the encoded path goes into the URL. In a repository you are not standing in, the pipeline's own `sha` is the only evidence of what is being deployed; check it against the commit you mean to ship. The user says only "dev" or "stage" most of the time. When they say neither and the task does not imply one, ask. ## The pipeline | Ref | Build | Deploy | Lands in | | --- | --- | --- | --- | | any branch but `main` | `Build`, manual | `Deploy.dev-az`, automatic once `Build` passes | the dev namespace, `$K8S_NAMESPACE_DEV` | | tag `vX.Y.Z` on `main` | `Build`, automatic | `Deploy.prod-az-core`, manual | the stage namespace, `$K8S_NAMESPACE_STAGE` | Migration repositories run flyway instead — `DEV-AZ:Migrate-main` on `develop`, `PROD-AZ-CORE:Migrate-main` on the tag, both automatic, and both finish long before any service deploy does. A repository with no `Build` job is one of those: nothing to trigger there and nothing to wait for, only a status to read. Merge request pipelines