ci: parameterized deploy workflows (lane / stack prefix inputs)

[gankoji]

TL;DR

Refactor GitHub Actions so deploy / promote / verify workflows accept inputs (lane, environment, git_sha) and read stack names + URLs from infra/ci/stack-map.yaml and environments/*.json — so adding v1.5 is mostly config, not copy-paste YAML.

Why this matters

Duplicated workflows drift; one bug fixes prod but not v1.5. Parameterization is how you scale lanes.

Prerequisites

• Issue infra: add stack map (env → Pulumi stacks + deploy order) #667 complete (stack-map.yaml checked in).
• Issues ci: auto-deploy main to dev (pre-prod Swarm) after green build #673–ci: integration test gate before prod deploy (staging-first) #679 implemented or well understood (you are generalizing working patterns).
• Install yq in CI or use small Node script scripts/ci/read-stack-map.mjs — pick one and reuse everywhere.

Glossary

Term	Meaning
Callable workflow	workflow_call with inputs — invoked by other workflows.
Lane	e.g. main, v15 — maps to contract file prefix and secret namespace.

What you will deliver

1. Reusable workflow .github/workflows/_reusable-pulumi-deploy.yml (name flexible):

   • inputs: lane, target (dev|staging|prod), git_sha, command (preview|up).
   • Reads stack order via yq from infra/ci/stack-map.yaml.
   • Selects GitHub environment input maps: development / staging / production — or lane-specific env names once they exist.

2. Thin wrappers:

   • cd-deploy-dev.yml → uses: ./.github/workflows/_reusable-pulumi-deploy.yml with lane: main, target: dev.
   • Same for staging promote + prod (or single dispatch with inputs).

3. Documentation in infra/ci/README.md: table of wrappers → reusable core.

Step-by-step

1. Extract duplicate YAML from existing workflows into reusable file without behavior change for main lane (parity test).
2. Add lane input defaulted to main for backward compatibility.
3. Replace hardcoded matrix in infra-pulumi.yml preview with calls to reusable preview job if it reduces duplication — optional sub-task.
4. Add one integration test: run reusable workflow with command: preview on pull_request path infra/ci/**.

Acceptance criteria

• main dev/staging/prod flows behave identically to before refactor (maintainer sign-off).
• Adding a new lane requires: new stack-map section + new env JSON + new GitHub Environment secrets — no new copy of Pulumi step blocks.
• README explains inputs for junior devs.
• No secrets in stack-map or lane config files.

Out of scope

• Actually creating v1.5 secrets/stacks (documentation issue docs: multi-lane pattern (v1.5/v2/v3) — contracts, isolation, routing #681).
• Non-GitHub CI systems.

If you get stuck

• GitHub reusable workflows cannot easily compose dynamic secrets: from objects — you may need explicit secret names per lane (secrets.PROD_SSH_KEY vs secrets.V15_PROD_SSH_KEY) passed from caller. Document the pattern.